**** BEGIN LOGGING AT Wed Feb 17 02:59:59 2016 Feb 17 04:07:06 the 12 MHz fix was not golden. Feb 17 04:08:21 the device disconnects and then reconnects for some unknown reason after a variable amount of time after a successful initial connection. but there is no babble itnerrupt reported at all. Feb 17 04:08:30 any thoughts? Feb 17 04:08:49 that time varies from 5 minutes to an hour as observed so far. Feb 17 04:24:24 the above is when the board is NOT connected to the wired ethernet (eth0) Feb 17 04:24:34 when it IS connected to eth0, everything works fine for hours... Feb 17 04:25:08 does this sound like a hardware problem or a software problem? Feb 17 04:34:02 Hello Feb 17 04:34:33 I am looking to become a Re-Seller of Beaglebone can you please provide me with some details Feb 17 04:36:08 please provide me with some more details.. I can be reached at ctpost2@gmail.com Feb 17 04:36:13 Thank you very much! Feb 17 04:43:26 zmatt: any ideas? Feb 17 05:05:24 yates: hard to say... I don't know off the top of my head what the criteria are for FS disconnection detect. Feb 17 05:06:43 for the HS babbles I was leaning towards things like noise pickup due to board layout issues, something that made the phy think the line was active when it wasn't Feb 17 05:07:13 otoh I don't think an FS disconnect can be triggered that easily, but I'm not sure Feb 17 05:09:09 the device is a WWAN thing right? are you sure its power supply is stable enough? Feb 17 05:09:23 since they're known to draw a lot of current in short bursts Feb 17 05:10:04 also, excellent candidate for RF-induced trouble obviously Feb 17 05:11:39 though again I don't see an FS disconnect happening by that... it requires both lines to go low, and I'm somewhat sure it requires this for longer than just a spike Feb 17 05:12:39 btw, is the vbus used for anything other than making the phy happy by presenting it on the vbus input? Feb 17 05:25:52 hang on... Feb 17 05:34:31 here is our schematic page: http://www.digitalsignallabs.com/le910.png Feb 17 05:36:05 the vbus input to the am335x is directly from the SYS_5V Feb 17 05:36:44 the phy is okay with that? good to know Feb 17 05:36:57 i guess... ? Feb 17 05:37:01 uhh Feb 17 05:37:30 waaaait, wut? Feb 17 05:38:20 what exactly does the LE910 do with its vbus input? :P Feb 17 05:38:45 considering it's normally a 5V power supply and you've got it connected to a 3.3V digital output Feb 17 05:39:12 (that cannot source any significant amount of current) Feb 17 05:39:44 or well, depends on what you call significant of course, but it's not a supply line in any case Feb 17 05:40:00 http://www.digitalsignallabs.com/le910-vbus-description.png Feb 17 05:40:22 looks ok to me Feb 17 05:41:28 okay Feb 17 05:41:41 3.3V > 2.0V Feb 17 05:42:05 right? Feb 17 05:43:26 yeah it might dip to 3V when drawing 5 mA if you've got weak silicon but that's still higher than the 2.2V requirement stated by that page Feb 17 05:46:22 there is a 100-ohm series resistor too Feb 17 05:46:43 that doesn't really have any impact on a 10K pulldown Feb 17 05:47:03 where/when does CELL_GND connect to the AM335x ground? Feb 17 05:47:17 eh, where/how I mean Feb 17 05:47:59 last i checked 5mA * 100 ohm = 0.5 V - that's significant Feb 17 05:49:23 point... how are they getting "max 5 mA with internal pull-down 10K"... Feb 17 05:50:23 I'm more concerned about the "CELL_GND" though, there should be a single continuous ground plane Feb 17 05:50:38 yes, that seems confusing - where is this 5ma Feb 17 05:50:58 occurs twice on http://www.digitalsignallabs.com/le910-vbus-description.png Feb 17 05:52:03 we had a layout snafu and some of the ground planes were left disconnected. somehow our hw guy has long-since jumpered them. Feb 17 05:52:19 don't ask me where/how.. idk Feb 17 05:52:24 that's not really a substitute for a continuous ground plane Feb 17 05:52:41 and routing traces across a split in the ground plane is bad Feb 17 05:53:21 so are you intimating that this reference could be flopping around (vbus input to le910)? Feb 17 05:53:44 or the usb lines themselves Feb 17 05:53:49 yah. Feb 17 05:54:15 try replacing the 100 ohm with 0 ohm Feb 17 05:54:25 that gets you 0.5V extra margin Feb 17 05:54:26 could it be that plugging in the eth0 starts up that regulator in the PHY and somehow equalizes the ground planes better? Feb 17 05:55:19 note that we found a eth loopback plug works too - don't have to connect it to any router or anything. Feb 17 05:55:36 lol Feb 17 05:55:36 true Feb 17 05:55:50 did i say something funny? Feb 17 05:56:04 the influence of ethernet on all this Feb 17 05:56:18 it's starting to make me cry. Feb 17 05:56:27 debugging signal integrity issues can feel a lot like this -> https://xkcd.com/1457/ Feb 17 05:56:30 to account for it.. Feb 17 05:56:48 yes. Feb 17 05:56:52 ha. Feb 17 05:58:49 https://xkcd.com/26/ Feb 17 05:59:27 but really, I've seen examples on how to deal with some unavoidable split in a ground plane (e.g. moving to another layer) and it involves sowing them together with a ton of vias, in particular close to any signal crossing the split Feb 17 05:59:39 "jumpering" them may not suffice Feb 17 05:59:50 especially not if you have a strong source of interference nearby Feb 17 05:59:54 say, a transmitter :P Feb 17 06:00:32 we've also been looking at some bluetooth module and they specifically warn against ground plane splits Feb 17 06:00:55 zmatt: point well-taken. believe me, i'd love to conclude it's the hardware. Feb 17 06:01:17 to be honest, i'm not sure how he fixed the ground plane issue. Feb 17 06:01:38 i may have used the term "jumper" loosely.. Feb 17 06:01:39 https://xkcd.com/754/ Feb 17 06:03:39 well the connection needs to have low resistance *and* needs to be near every signal that crosses from one plane to the other Feb 17 06:04:24 so why does connecting the eth0 solve this problem, with 100 percent reliability, across 3 different boards?!?!?!? Feb 17 06:04:44 hardware? software? hardware? software? hardware? software? hardware? software? hardware? software? Feb 17 06:05:14 one of those two I'd guess yes Feb 17 06:05:22 going nite nite. thanks (as usual) for the stimulating thoughts, matt. Feb 17 06:05:23 ha ! Feb 17 06:06:04 at least you have the vbus resistor thing to try as possible easy fix Feb 17 06:06:09 maybe you're lucky Feb 17 06:06:24 yes, maybe - worth a try Feb 17 06:07:44 if not, see if the ground planes can be sowed together somewhere near crossings of critical signals Feb 17 06:08:21 also... test points on usb? split ground planes? maybe slap the pcb designer? :P Feb 17 06:09:49 like, I'm not a hw designer but pretty much every doc with guidelines I read would have warned about split planes Feb 17 06:14:54 g'night Feb 17 06:21:41 hmmm Feb 17 06:25:30 ds2: you know PRU pretty well right? if it were used to receive 4-bit (+ clock) synchronous serial data, what would the max clock speed be? Feb 17 06:26:30 (I was pondering about the trace output port, for which you normally need a fairly high-end debugger to be able to use it) Feb 17 06:27:42 hmmm let see Feb 17 06:27:52 btw, how's the composite video project going? :) Feb 17 06:27:55 4 bit in parallel or 4 bit signals? Feb 17 06:28:09 composite video is working great.... color still requires thinking Feb 17 06:28:45 trying to do SDR but other projects are demanding attention Feb 17 06:29:29 it's one datastream, served in nibbles across 4 wires Feb 17 06:30:59 a la QSPI Feb 17 06:31:20 maybe 30MHz Feb 17 06:31:22 nibbles are also the most natural way to parse it since every packet is one opcode nibble followed by zero or more data nibbles Feb 17 06:31:30 problem is that clock is not sync to the PRU Feb 17 06:32:31 it has a "parallel latch" mode for its inputs right? that should help at least a bit? Feb 17 06:32:37 something like while(clock HIGH); read; save; while(clock LOW) Feb 17 06:32:44 nope. no help Feb 17 06:33:07 I cankind of keep up capturing 8bits @ around 27MHz Feb 17 06:38:52 so it's not much faster than using 1-bit serial trace with its shift-in mode... (though you can get away with a crappier connection with 4-bit at lower clock...) Feb 17 06:39:23 well, and assuming trace output supports such frequencies, there's nothing in the datasheet about it -.- Feb 17 06:41:31 and yeah, colors, I read this article with some fascination -> https://en.wikipedia.org/wiki/Composite_artifact_colors Feb 17 06:42:05 hadn't realized it's that easy to reach the required frequencies Feb 17 06:44:01 yes Feb 17 06:44:41 frequency is not the issue; it is all about phasing Feb 17 06:44:57 the "Microsoft Decathlon" example is also very striking... in NTSC-optimized mode the text is unreadable on an RGB monitor and vice versa Feb 17 06:45:20 heh...reminds of the atari days Feb 17 06:45:47 80 col only doable on proper RGB monitor; otherwise things alias Feb 17 06:46:45 I don't think I ever had any computer that used a TV as display... but I grew up with Macs and wasn't really a gamer Feb 17 06:47:02 ah Feb 17 06:47:13 for extra fun, read about programming graphics on the Atari 2600 Feb 17 06:52:00 Hey, anybody awake right now? Feb 17 06:52:18 it sucks though that only STM can do hardware trace output... ETM is limited to tracing to the crappy ETB Feb 17 06:52:20 ENOCAFFINE Feb 17 06:52:46 * zmatt sends ds2 some caffeine powder Feb 17 06:52:52 Anybody here get the beaglebone black to work from an Arch Linux host? Feb 17 06:52:55 are you trying to build a ETM analyzer? Feb 17 06:52:59 I can't find anything on the internet about it :< Feb 17 06:53:33 Poplar: what is not working? Feb 17 06:53:43 I can't see it from my Arch laptop Feb 17 06:53:44 At all Feb 17 06:53:52 USB or Serial port? Feb 17 06:53:57 USB Feb 17 06:53:58 ds2: well, real-time trace would be a useful thing to have in one's toolbox Feb 17 06:54:11 Ran the .sh file, it won't ping 192.168.7.2 Feb 17 06:54:17 And no new interfaces are showing up Feb 17 06:54:29 zmatt: FPGA on GPMC might be the best bet Feb 17 06:54:46 lsusb isn't really showing anything useful, except that this computer might be so old some of the usb ports aren't usb 2.0... Feb 17 06:54:56 Poplar: maybe you need the USB net stuff ? Feb 17 06:55:24 Can't find any decent documentation Feb 17 06:55:48 I'd really like to get this actually working so I can bring this laptop and actually do work Feb 17 06:55:54 <-- don't do distros Feb 17 06:56:12 It seems like it works for other linux distros but for some reason isn't working on Arch and I have no idea why Feb 17 06:56:50 probally needs some package Feb 17 06:57:10 Like I said, can't find any documentation Feb 17 06:57:16 ds2: I don't see why PRU would not suffice... but more importantly, as I mentioned, on the am335x ETM can't trace to hardware output anyway, only to ETB Feb 17 06:57:52 zmatt: PRU by itself sure, but you get bogged down transfering data Feb 17 06:58:06 2 clocks to write to local sram Feb 17 06:58:15 more outside to sdram Feb 17 06:58:25 writes are posted Feb 17 06:58:47 not for sram Feb 17 06:59:09 posting works only to a point (first write, second write needs first write to clear) Feb 17 07:00:10 eh, only if the destination is bogged down Feb 17 07:03:22 I understand offloading can require creativity (e.g. passing it to the other PRU which can write to SRAM in batches to avoid paying the 2-cycle penalty for each write, maybe have EDMA grab the data from there), but PRU still seemed like the best bet to be able to use an off-the-shelf BBB Feb 17 07:03:59 if you got the other PRU free.... Feb 17 07:04:04 which itself still seems like the best low-cost off-the-shelf solution in general Feb 17 07:04:22 the SRAM write is 1 + number of 32bit words long Feb 17 07:04:26 Gahh I'm going to die before I figure this out :< Feb 17 07:04:43 Poplar: you chose arch :P Feb 17 07:04:54 arch chose me Feb 17 07:04:58 hehe Feb 17 07:05:27 1.7GHz Intel M, 1GB DDR 400, 80GB IDE drive, Intel... I don't even know how old the graphics are Feb 17 07:05:48 ds2: ideally it would also do JTAG, could make a nice debug/trace solution in theory Feb 17 07:05:52 This is my like 3rd favorite laptop ever made though :< Feb 17 07:06:05 zmatt: That was failed GSoC project Feb 17 07:06:10 certainly better than the usual FT2232H-based debuggers -.- Feb 17 07:06:30 really? what exactly and failed how? Feb 17 07:06:41 student Feb 17 07:06:47 didn't finish Feb 17 07:07:04 so if you want to help mentor.... Feb 17 07:08:28 ... Feb 17 07:09:52 I know icepick and ADIv5 well enough that I could probably do a bus transaction if you'd give me some switches on the jtag (and a led for TDO) and a list to reminde me of the IR codes :P Feb 17 07:12:55 unfortunately I'm not as good at converting knowledge into code as I am in acquiring knowledge Feb 17 07:13:55 (perfectionism, premature optimization, getting distracted, etc -.- ) Feb 17 07:33:28 Hello My name is Bastiaan, and recently bought a Beaglebone Black, and would like to program efficiently Feb 17 07:47:03 Bastiaan, what do you mean efficiently? Feb 17 07:48:52 I would like to create seperate processes that record Temperature measurements from thermocouples over SPI, over the Arduino Programming Language in the BBB. Feb 17 07:50:06 translate: you want to write a temperature logger in c. Feb 17 07:50:08 furthermore I would like to steer with the MAX8521 the Peltier on a accurate Room Temperature. I discovered that the Arduino is fast but, becomes slower because of the Void Loop. Feb 17 07:51:08 how is this on the Beaglebone? Feb 17 07:51:52 i think you went somewhere in your thinking Feb 17 07:52:11 LetoThe2nd: "in weird butchered C" you mean ;P Feb 17 07:52:17 i am really absolutely sure that any arduino is totally fast enough to control a few temperatures and a peltier Feb 17 07:52:39 indeed Feb 17 07:52:43 e.g., the problem is mostly not the hardware, but the technique you used - not the hardware. Feb 17 07:52:53 gah. butchered sentence. Feb 17 07:53:56 and "the void loop" is not anything that is good or bad per se - its what you make of it. and somewhere deep in its heart, linux runs a while(1): loop too..... Feb 17 07:55:05 so step #1 should be to take a good look at your code, requirements and techniques, before bluntly saying "i want to efficiently program a BBB" (because that sentence doesn't make any sense anyways.) Feb 17 07:56:09 well that sentence *can* make sense, but making _efficient_ use of the resources on the BBB is 1. complete overkill 2. much much harder than making efficient use of an arduino Feb 17 07:56:33 and given your requirements for the word "room", depending on its size probably a few MHz cheapo uC will suffice. Feb 17 07:56:54 zmatt: without contect, it doesn't make sense - and i see none given here. Feb 17 07:56:58 on previous occasions I created a Soldering Device by used a LTC1050 with LTKA001 for thermocouple measurement, then a PID with a Control loop and a ST7735 Display + RTC Feb 17 07:57:46 ok, and? Feb 17 07:58:30 one of the loops was to record the temperature 100x, save it and log it on the SD card. at a certain point I could not log anymore because of the Space used in the Arduino, (yes I know I should write my own programs) Feb 17 07:59:04 therefore I was asking what could be a good start and where to start over. Feb 17 07:59:30 then get a nxp xpresso or how they are called. for a few bucks you get a non-bloat relatively high performance m0 or m3 board. Feb 17 07:59:56 and yes, logging to sd is often a PITA. Feb 17 08:00:14 you'll be faster on an arduino, unless you utilise the PRU modules on the BBB Feb 17 08:00:26 so your real problem is not the prformance of the controller, but the data logging infrastructure - thats how it sounds. Feb 17 08:00:59 veremit: depending on the meaning of the word 'room', we are talkng of processes that take minutes to hours in their control delays... Feb 17 08:01:20 LetoThe2nd: ah so no 'performance' rquired :D Feb 17 08:02:31 LetoThe2nd: lpcxpresso Feb 17 08:02:39 zmatt: yearight Feb 17 08:02:51 good cheapo controller, lots of power, raw control. Feb 17 08:02:54 so beaglebone can run seperate Loops? yes arduino /machine programming is nice, I know I had to learn it but It will take some time. Feb 17 08:03:06 ok ok:) Feb 17 08:03:52 good cheapo controller, lots of power, raw control. Feb 17 08:03:55 Bastiaan: well of course it can run seperate processes, but multiple processes does not mean multiplication of performance, rather a division, plus a sustantial penalty. Feb 17 08:03:57 I want to have high accuracy measurement as in 0.00C° less then 1ms is that achievable? Feb 17 08:04:12 ah ok that information is useful. Feb 17 08:04:43 Bastiaan: 1ms response time hard requirement in a standard linux including I/O is hard to impossible, i'd say. Feb 17 08:05:10 on a X * 10MHz m3, no magic Feb 17 08:05:14 I've measured irq latency to userspace at 44-88 μs, with some outliers if not using RT scheduling Feb 17 08:05:45 zmatt: right, and then add spi i/o plus context switched - bang, you are doomed. Feb 17 08:06:00 this already includes context switch overhead Feb 17 08:06:03 that what I was affraid of. Feb 17 08:06:26 does this also count for the E *? Feb 17 08:06:37 or beaglebone? Feb 17 08:06:39 zmatt: not for the i/o calls in between Feb 17 08:06:51 what is an "E *" Feb 17 08:07:10 but you're right it's difficult to guarantee low latency, though using an RT kernel and proper application structure should work in practice Feb 17 08:07:31 logging should not be done from the RT thread in any case Feb 17 08:07:45 since that doesn't have realtime requirements Feb 17 08:09:04 but basically we're back at step #1 Feb 17 08:09:22 it's still something easier done on a cheap uC than on a BBB Feb 17 08:10:00 yeah. one can always add a serial interface to get the data out and then log it on a bbb. Feb 17 08:10:11 this on the other hand would make sense, IMHO Feb 17 08:11:16 well, having plentiful RAM should suffice to decouple the logging (which to SD of course takes wildly variable time) from the real-time control Feb 17 08:11:40 an lpcxpresso is already a big step up from an arduino in that aspect Feb 17 08:12:28 (also, get a decent card) Feb 17 08:12:56 ok. good back to the first point. logging data is not neccesary, but displaying it would be nice. I did some programming with Java, and learned to use threads to display information from a to b. Feb 17 08:12:57 robust logging to sd card can be a major PITA, in my experience. if i have the possibility, i'd always go for uC + seperate linux for that. Feb 17 08:13:33 Bastiaan: uC 'threads' != java threads. and that is GOOD! Feb 17 08:14:53 I know... but threads cannot be created in a Arduino, you can only give variables from A to be through Pointers. Feb 17 08:15:24 Bastiaan: as usual - put your control in a mid-prio interrupt at 1ms, display control in the polling loop. take a little care for volatile variable storage, but as long are its not more than a handful of data values, its trivial Feb 17 08:15:48 no pointers, no threads, no nothing. and cheap context switches through the arm interrupt system. Feb 17 08:16:09 keep it simple ok. Feb 17 08:16:17 simple -> fast. Feb 17 08:16:52 i mean, one of your first words was "efficient", right? it was not me who came up with it :-P" Feb 17 08:17:10 I discovered that the PID loop is quite fast, is there also a RAMP code in beaglebone? Feb 17 08:17:18 :D Feb 17 08:17:32 or like S curves? Feb 17 08:17:33 threads lead to mutexes, mutexes lead to sadness in general and priority inversion in particular Feb 17 08:17:49 huh? ramp code? s-curve? Feb 17 08:18:06 LetoThe2nd: I'm guessing some std library code for the arduino Feb 17 08:18:27 zmatt: probably. or something claiming to be pid although it isn't. Feb 17 08:18:56 S curves are higher order polynomes that smooth a mechanical moving part during start up. Feb 17 08:19:11 pid controllers are trivial... (if you ignore the problem of tuning them) Feb 17 08:19:29 zmatt: rofl Feb 17 08:19:43 Bastiaan: so its some function you chain after the pid. or switch, time based. Feb 17 08:20:06 Bastiaan: well its only code, right? get a c implementation, add it. Feb 17 08:20:07 at the beginning of the start up and the end. Feb 17 08:20:33 Defiant: what? :) Feb 17 08:21:42 anyways, gotta run off and earn some money. Feb 17 08:22:23 :) ok; I have to calibrate some stuff. Thanks for the feedback! Letothe2nd keep on reading Dune:) Feb 17 08:23:41 <_av500_> which cpu runs the void loop fastest? Feb 17 08:24:08 _av500_: hm, let me get you that LKML thread on bogomips Feb 17 08:24:13 of the mentioned cpus, the cortex-a8 :P Feb 17 08:25:26 as long as you avoid mispredicted branches since too many of those will let PRU win, but an infinite loop doesn't have that problem :P Feb 17 08:26:51 (13-cycle penalty for mispredicted branches on the A8, while PRU branches always execute in 1 cycle) Feb 17 09:18:25 Never seen a white man head of the NAACP.. Feb 17 09:18:56 Black lives matter, in the same way that every god damn life matters Feb 17 09:18:58 Fuck Feb 17 10:15:05 http://www.hotmcu.com/wiki/Beagleong_Black_LCD_Display_with_Stereo_Audio_Cape Feb 17 10:15:30 anyone in here already try this cape? Feb 17 10:21:12 why angstrom, why?! Feb 17 11:03:31 <_av500_> veremit: because its an obsolete wiki page Feb 17 11:03:53 <_av500_> ah no Feb 17 11:03:57 _av500_: Another obsolete wiki page ?! ;) Feb 17 11:04:03 <_av500_> its from feb 15th Feb 17 11:04:08 Hello guys. I've got a beagleboard-xm board. From http://beagleboard.org/latest-images, I downloaded the image Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img.gz, and put in on the sdcard. From there, I opened the terminal, but many opkg operations fail with "Not found Feb 17 11:04:08 yeah a year old Feb 17 11:04:22 Hello guys. I've got a beagleboard-xm board. From http://beagleboard.org/latest-images, I downloaded the image Angstrom-TI-GNOME-image-eglibc-ipk-v2012.01-core-beagleboard-2012.01.11.img.gz, and put in on the sdcard. From there, I opened the terminal, but many opkg operations fail with "Not found" errors on urls. Feb 17 11:04:26 farkin freenode .. ffs. Feb 17 11:04:33 <_av500_> so somebody just copy pasted it from an ancient wiki page Feb 17 11:05:00 You have an idea what's wrong? Even opkg update fails. Thanks. Feb 17 11:05:21 Samuel: if you're using a 2012 image .. you're on ya own. Feb 17 11:05:38 hmmm... can I use then a newer image for this board? Feb 17 11:05:46 -facepalm- Feb 17 11:05:52 I was worried on compatibility problems Feb 17 11:06:13 <_av500_> Samuel: use the debian image Feb 17 11:06:13 <_av500_> not angstrom Feb 17 11:06:14 from what I saw on that page, that was the only image that supported "beagleboard-xm" Feb 17 11:06:23 <_av500_> ah, XM Feb 17 11:06:45 Samuel: http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#2015-11-03 Feb 17 11:06:51 I'm pretty sure there are more recent debian images Feb 17 11:06:53 there you go Feb 17 11:07:15 unless I'm mistaken .. although .. Xm .. hrm Feb 17 11:07:18 actually not XM Feb 17 11:07:26 <_av500_> undo Feb 17 11:07:29 yeah XM is an old board Feb 17 11:07:40 so I shouldn't try an image from that link, then? Feb 17 11:09:14 a "beagleboard beaglebone" image is not compatible with "beagleboard-xm", I suppose. Feb 17 11:10:54 http://elinux.org/BeagleBoardDebian .. let me digest Feb 17 11:11:53 https://eewiki.net/display/linuxonarm/BeagleBoard Feb 17 11:12:09 yeah if you're confident with rolling your own .. https://eewiki.net/display/linuxonarm/BeagleBoard Feb 17 11:12:12 that should still apply Feb 17 11:12:20 however if you want an image out-of-the-box .. Feb 17 11:12:39 wish rcn-ee would fix his SSL cert lol Feb 17 11:13:22 works for me Feb 17 11:15:20 I get a security warning .. but it could be my ancient browser Feb 17 11:15:45 ok, I'll check it out, thanks Feb 17 11:16:00 if you need help with particular steps, let us know Feb 17 11:16:08 looks like there's a demo image on http://elinux.org/BeagleBoardDebian#Debian_.28jessie.29 Feb 17 11:16:13 also there might be other working images we're not aware of Feb 17 11:17:23 ah, right, that's the tarballed 'images' which come with scripts Feb 17 11:17:51 ymmv image/scripts lol **** BEGIN LOGGING AT Wed Feb 17 12:00:09 2016 Feb 17 12:44:40 Hello. Anyone there who knows how to install a BB Black wifi dongle? The dongle is that arrived in the box but: Feb 17 14:43:31 whats the best choice to build kernel for beaglebone black. robert nelson kernels or yokto or ...? Feb 17 14:47:03 the official kernels are all built via RN's scripts & patches .. so .. Feb 17 14:48:39 and when it comes to those, I'd go with the vanilla+patches not the TI patched ones, but that's just me Feb 17 15:06:16 but as i see qt5 scripts are based on yokto project, also i forgot to say: there is also ti kernels for RCN's so ... Feb 17 15:06:40 *yocto sorry Feb 17 16:16:22 I'm trying to read PRU sram from kernel space. All my research indicates a simple ioremap & ioread32 will work, yet that gets Unhandled exception. This leads me to belive I'm missing something simple. Any clue what that may be? Feb 17 16:22:09 I don't know - but I got VisualPRU running and it works great https://github.com/mmcdan/visualpru Feb 17 16:42:10 anyone can help me to set bluetooth (HC 06) on my beaglebone Feb 17 16:42:22 anyone can help me to set bluetooth (HC 06) on my beaglebone Feb 17 17:27:25 Ragnorok: is PRUSS actually enabled? Feb 17 17:28:21 Afaik it is. At present I have a firmware that's loading via pruss_remotproc on boot, which I presumed did the magic to enable it. Feb 17 17:28:36 hmm Feb 17 17:29:43 I'm happy to roll back to uio or whatever, if it will let me actually do soemthing. This kernel (latest deb 8.3 from bbone.org) doesn't seem to have uio_pruss built. It's got remoteproc. Feb 17 17:30:29 Remoteproc seems to have no usable data on interacting with the PRU dynamically. Or it's there and my search foo has sucked for ten days straight. Feb 17 17:30:47 install a -bone kernel Feb 17 17:30:56 those still have uio_pruss Feb 17 17:31:51 Ok. Just for curiousity, why doesn't the beaglebone.org image have a -bone kernel? Feb 17 17:31:59 note that you can also map memory regions and receive irqs using uio_genirq_pdrv which is part of mainline linux Feb 17 17:32:13 (and enabled in all of rcn-ee's kernels) Feb 17 17:32:24 no idea, you'd have to ask rcn-ee Feb 17 17:32:57 My research indicates ioremap is the way to go, but that's not working. I'll look up how to use uio_genirq_prdrv and see where that leads, before reflashing. Feb 17 17:33:08 no need to reflash Feb 17 17:33:11 just switch kernel Feb 17 17:34:11 e.g. sudo apt-get install linux-image-4.1.18-bone19 Feb 17 17:34:18 or sudo apt-get install linux-image-4.4.1-bone5 Feb 17 17:34:31 Sadly my research into how to do that has also born no fruit. I'm under the impression it's a simple as copying a file or two, but I've not seen any clear indication of what files go where. I have a 4.1.17 I build that I could use. Feb 17 17:34:56 first run sudo apt-get update Feb 17 17:35:02 then one of the two commands above Feb 17 17:35:03 Will the 4.1.18 work with the kernel modules build for 4.1.15 that's on there now? Feb 17 17:35:52 every kernel package includes its own modules (there's a subdirectory in /lib/modules for each kernel version) Feb 17 17:36:10 Ok. I know about the subdir, not that each was packaged with same. Thanks. Feb 17 17:37:19 I have a 4.1.17 rcn kernal I built but I could figure out how to install it. About everything I found was how to use remote boot. Feb 17 17:37:29 could not* Feb 17 17:37:49 But I can do 4.1.18-bone19 instead. (shrug) Feb 17 17:38:42 if you use rcn-ee's build_deb.sh you can use dpkg -i FILENAME to install the linux-image-whatever.deb Feb 17 17:38:51 This install is on the BBB I presume, that being where I want the image. Just making sure; often little bits like that are missing from instructions. (grin) Feb 17 17:39:01 yes it's on the BBB Feb 17 17:39:18 "sudo apt-get update" will fetch the latest package lists Feb 17 17:39:35 sometimes you get some error about size mismatch, this is a known bug you can ignore Feb 17 17:39:44 Ah. This doesn't doesn't a build.sh. It's a rcn kernel but I don't recall where I got it; I think it's one where he used the ti one instead of the -bone one. Feb 17 17:40:15 Yeah. Did the udpate. Feb 17 17:41:11 when you install a kernel package it'll automatically change your /boot/uEnv.txt to use the new version Feb 17 17:41:29 Right. So I'll have to re-tweak that. Feb 17 17:42:01 to do what? Feb 17 17:42:21 it only changes the uname_r= line Feb 17 17:42:21 I have a custom overlay that's configured in uEnv. I'll have to put that back. Feb 17 17:42:27 Oh. Ok. Feb 17 17:42:56 I thought you were saying it replaced it. (grin) Feb 17 17:45:09 It says it couldn't find the headers. Feb 17 17:45:48 oh that's dkms complaining Feb 17 17:45:54 Yup. Feb 17 17:46:22 I have my dir in /lib/modules though, so I should be good. Feb 17 17:46:26 note that it's not a fatal error or anything, but you can either install the headers (sudo apt-get install linux-headers-VERSION) or remove dmks if you're not using it Feb 17 17:46:53 *dkms Feb 17 17:47:05 Since I don't know what dmks is I'm not intentionally using it. (grin) Feb 17 17:47:32 it's a system to automatically rebuild kernel modules from source when a new kernel is installed Feb 17 17:47:36 that's why it needs the headers Feb 17 17:47:46 Makes sense. Feb 17 17:47:47 it's probably included as a convenience for custom kernel modules Feb 17 17:48:37 either that or it actually builds some kernel module, like those for sgx maybe Feb 17 17:48:45 dunno Feb 17 17:49:02 (shrug) I'll ignore it for now. Feb 17 17:52:01 I think I'll need the headers. Build in the kernel modules links to there. Feb 17 17:56:23 sounds like it probably uses dkms :) Feb 17 17:57:49 Ah. See. Didn't know I was using it. Feb 17 18:30:55 Hurm. It doesn't appear to boot up now. At least I don't see any bootp packets, or anything with Texas in the ethernet source in Wireshark. Feb 17 18:31:39 Normally eth.src_resolved contains Texas will show me BBB packets. Feb 17 18:34:30 uh, that sounds odd, I've never had problems switching kernels Feb 17 18:34:45 I don't suppose you have a serial cable to see what's going on? Feb 17 18:35:35 It's my computer karma. I routinely have issues that result in "I've never seen that" from others. (smirk) I do. Let me see if I can get it work. I'm thinking 'nix will have been luck than win. Feb 17 18:37:15 well then maybe avoid meddling with the kernel ;) I personally do basically everything from userspace Feb 17 18:37:39 in my case that even includes doing DMA though, so some people will think I'm nuts XD Feb 17 18:41:48 zmatt: idk, I’ve implemented a bitbanged network interface by, in part, reading/writing shared PRU memory from userspace. felt good about it Feb 17 18:42:37 zmatt: Well I kinda have to do some kernel work, but I'm looking to minimize it. Feb 17 18:43:14 That part actually went pretty smoothly, creating devices & /sys bits. Feb 17 18:43:58 dmesg says I have a FTDI at ttyUSB0. Let's see what happens. Feb 17 18:50:00 James_Johnson: yeah my only peeve is that userspace mappings of device space (using uio or /dev/mem) are currently Strongly Ordered unlike kernel mappings which are Device type Feb 17 18:50:08 still need to see if I can fix that Feb 17 18:50:39 my attitude is “well it works and I won’t worry about it until it breaks" Feb 17 18:51:54 yeah, fair enough, it's also not high on my priority list but it just slightly annoys me because I know a strongly-ordered write takes about 150 cycles (versus 1 cycle for a device write) Feb 17 18:54:21 Never done cosole on a BBB so I don't know what's normal, but I have a number of "errors" end in a UBoot prompt. Feb 17 18:54:49 the uboot prompt ending is not normal Feb 17 18:55:03 Biggest seems to be it can't find a flattened device tree. Feb 17 18:55:34 oh, you're using a non-standard dtb? Feb 17 18:55:35 Oh. I see. I needed to copy some stuff to /boot/dtbs/4.1.18-bone19 so it could find it. Feb 17 18:55:47 you can place custom dtbs also just in /boot/dtbs/ Feb 17 18:55:53 then any kernel version will find them Feb 17 18:56:01 Yeah. Thats why I said I thought I'd have to update uEnv. Feb 17 18:56:31 Can I do that from the UBoot prompt or do I have to boot to emmc and do it that way? Feb 17 18:57:31 you can manually boot with custom options but I would need to look up the commands... it's probably easier to put the BBB in UMS mode and fix the situation from your host machine Feb 17 18:57:48 Roit toe. I was thinking that. Thanks. Feb 17 18:57:49 if you type "ums 0 mmc 1" at the u-boot prompt, the BBB's eMMC will appear like a USB stick on your computer Feb 17 18:57:51 or uSD boot Feb 17 18:58:42 * Ragnorok is researching UBoot commands Feb 17 18:59:55 Apparently it's crashed. The UBoot command line doesn't respond. (pout) Feb 17 19:01:09 Ragnorok: that's normal if you enter ums mode Feb 17 19:01:59 Ok. I just rebooted to emmc. I can mount the SD and copy the files and reboot again. (shrug) Feb 17 19:02:43 huh, oh you're working on SD card rather than eMMC ? Feb 17 19:02:49 Yeah. Feb 17 19:03:36 which means you even could just have mounted the card on your computer to fix the situation :P Feb 17 19:05:47 Could have. Still had to shut down the BBB to pop the card, and if I use the BBB I don't have to dig up a micro SD reader. Feb 17 19:06:25 sure, this works too, plenty of options Feb 17 19:07:39 lol Feb 17 19:08:36 lol... poor kids... https://www.youtube.com/watch?v=B8SkGoNf_gM Feb 17 19:08:37 Starting kernel ... \o/ Feb 17 19:58:43 zmatt - omg thats hilarious - a canteloupe mixed with a fart! Feb 17 20:47:19 evening Feb 17 20:49:03 first BBB. upgrading the image. did a dd of debian-8.3 onto an SD card. put SD card in BBB and pressed user button before powering via USB Feb 17 20:49:42 think i got the user button wrong Feb 17 20:50:55 do i use the boot switch? Feb 17 20:52:04 I didn't have to. It just uses the uSD all the time, when it's plugged properly. Feb 17 20:54:43 ah, i thought it booted eMMC flash by default Feb 17 20:55:32 You can tell by doing uname -a. If it's 3.8.x you're on emmc, if it's 4.1.x, uSD. Every once in a blue moon it doesn't boot to uSD, in which I just reboot. (shrug) Feb 17 20:56:26 zmatt: Now that I'm using this bone kernel I'm thinking I need to enable the PRUs and other stuff as related to prior findings on uio_pruss. Feb 17 21:04:22 when booting off the SD card, will it work with just usb cable plugged in? (usb/network bridge) Feb 17 21:04:48 Afiak. Feb 17 21:06:43 my dhcp client hangs on getting IP for the usb network interface Feb 17 21:06:55 booting off the flash is fine :( Feb 17 21:10:07 Huh. I avoid USB whenever possible. I have a wart & ethernet for the BBB. Feb 17 21:10:21 wart? Feb 17 21:10:34 Wall wart. Feb 17 21:10:49 Something for the barrel jack to play with. Feb 17 21:23:38 hmm. can i boot off jessie on an SD card or is the image for flashing only Feb 17 22:04:56 The one you mentioned is what I was booting from until just a couple of hours ago. Feb 17 22:06:18 Thanks zmatt. We'll see how things go now. Feb 17 23:45:00 zmatt cow tongue isn't bad just be sure it's peeled first :D Feb 17 23:45:40 the kids being tortured with extra salty liquorice is funny too Feb 17 23:46:39 though they attribute it to Finland while the actual liquorice looks suspiciously Dutch (unless by sheer coincidence the initials "DZ" on liquorice has meaning in Finnish as well) Feb 17 23:47:21 somehow I find that unlikely. (DZ meaning Finnish) Feb 17 23:47:42 (it's Dubbel Zout in dutch btw, "double salt") Feb 17 23:47:47 "double salty" Feb 17 23:48:52 KIMCHI might be interesting as that is very spicy Feb 17 23:49:28 in highschool we had some exchange program with a spanish school, so I know how funny it can be to feed it to unsuspecting kids, the "eject! eject! eject!" look ;) Feb 17 23:55:15 I don't know why VEGEMITE exists but I'm not a fan of it myself. My Brother however is a different ... person so I guess he has an excuse. Feb 17 23:55:35 Amanda Palmer also has a funny song about it Feb 17 23:56:06 Vegemite (The Black Death) Feb 17 23:57:57 there is an australian bar here in vienna and i just ordered toast with vegemite not knowing what it was . . . lets just say i was disappointed :D Feb 17 23:58:45 https://www.youtube.com/watch?v=fVKPrQv1H8I Feb 17 23:59:46 Well I guess black death isn't too far off. I still can't figure out why someone actually made it. Probably because it was all they had left over after eating everything else and they made "vegemite" Feb 18 00:19:51 hmmm haggis Feb 18 00:19:56 Ahem :D Feb 18 02:35:37 hi Feb 18 02:35:58 if anyone can help, I can't access the Connman library to enable bluetooth, any suggestions? **** ENDING LOGGING AT Thu Feb 18 02:59:59 2016