**** BEGIN LOGGING AT Mon Aug 29 02:59:58 2016 Aug 29 03:17:07 woo :) Aug 29 03:38:35 hi Aug 29 03:48:02 hi Aug 29 03:49:39 Which image should I flash into a new bbb the one on beagleboard.org or the one on elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC Aug 29 03:52:51 they're basically the same, but the former are the "official" releases while the elinux wiki often lists newer snapshots Aug 29 03:53:07 also, the elinux wiki has ready-to-use eMMC flasher images Aug 29 03:53:45 (these are labeled "flasher" rather than "standalone") Aug 29 03:54:13 while beagleboard.org only has standalone images and instructions on how to make a flasher Aug 29 03:54:29 (deliberately: "Images are no longer provided here for this to avoid people accidentally overwriting their eMMC flash.") Aug 29 03:55:10 I generally recommend the latest snapshot from the elinux page Aug 29 03:55:37 ooh awesome thanks, I tried turning the image in the beagleboard page into an eMMC flash using the command provided but it wouldn't allow me to Aug 29 03:56:16 will these flashing erase any files/folders I might have on the bbb? Aug 29 03:56:58 (lxqt if you need a GUI, iot if you don't need a GUI but do want the other stuff like the webserver with cloud9 ide, console if you want a minimalistic system and just install/setup things as you like) Aug 29 03:57:02 yes Aug 29 03:57:11 flashers will completely overwrite eMMC Aug 29 03:57:34 ok thanks Aug 29 09:28:55 hi everybody Aug 29 09:31:31 can someone help me? I need to use the standard type A usb as a network interface, but doing ifconfig shows me only the usb0 device, is there's a way to have a usb1 associated to the type A usb? Aug 29 09:47:38 Pitagoric: um, can you try to explain more about what you are trying to do? on which side are you working board or computer? Aug 29 09:48:55 hi tbr, I need to create a simple point to point lan between a BBB and an edison board Aug 29 09:49:03 using a standard usb cable Aug 29 09:49:43 ok and which side is host and which is device? Aug 29 09:50:48 which side has the USB-A plug and which the (micro|mini|regular)-USB-B plug? Aug 29 09:52:42 this is the plan usbA-on-BBB <----------> usbA-on-edison Aug 29 09:54:41 but the only active network device as a usb interface in the BBB is the one associated with the micro usb, and ifconfig shows it as a ubs0 network device and I can't use it because I have this usbA-to-usbA constraint Aug 29 10:17:54 you don't make sense Aug 29 10:18:27 you can't connect two USB-A ports (unless you somehow force device mode on one side) Aug 29 10:31:04 can anyone please advice me when to solder a sys +5v from? I am now using P9_7 but I want a small wire warp thread to solder Aug 29 10:32:28 preferably during a harvest moon and in the presence of a virgin. Aug 29 10:37:20 tbr: does something sold by virgin records suffice too? Aug 29 10:38:03 LetoThe2nd: in a pinch Aug 29 10:38:20 LetoThe2nd: a Virgin Atlantic airplane would do as well Aug 29 10:48:28 alternatively: use chicken blood in bowl of gold Aug 29 11:25:10 tbr yeah I see the point my intentions were a bit silly I admit, but...what if I want something like this bbb-usbA <-----> usbB-edison Aug 29 11:26:04 my issue here is that the bbb sees the usb a storage device instead as a network device, I guess that's because it a standard host usb Aug 29 11:35:22 Pitagoric: you'll need to set up your edison as a usb ethernet. . same way the bbb is on its mini-B Aug 29 11:35:33 something called the gadget driver interface Aug 29 11:35:44 although it's been partially superceded Aug 29 12:22:54 sorry if I reaply a little late, but eventually I managed to resolve my problem and created a point to point network between BBB and edison over usb. I connected the usbA of the BBB to the micro usb in the edison, but the issue was that the usbA on the BBB wasn't working and appartly someone found a work around (https://groups.google.com/forum/?fromgroups#!category-topic/beagleboard/beaglebone-black/nuyyVDhU6bw) which enabled a usb1 Aug 29 12:23:23 then I just set the correct ips on both sides and it worked fine Aug 29 16:18:08 probably the root cause is too much inrush current messing with the power supplies of the bbb Aug 29 16:18:13 oh, he left Aug 29 16:18:46 Maybe it'll come to him by osmosis via the aether. Aug 29 16:18:52 or logs Aug 29 16:30:42 on the bottom side of the BBB the 5V pin of the USB is very close to pin 1 (GND) of U8 (the usb power switch) Aug 29 16:30:53 excellent setup for adding a fat cap Aug 29 16:31:09 the lack of which is no doubt a significant part of the usb issues Aug 29 16:31:51 ah a 470uF POSCAP 6.3V would be perfect then :D Aug 29 16:32:02 actually .. thats a bit big .. Aug 29 16:32:07 iirc the power switch recommended 100 uF Aug 29 16:32:09 100uF is the design requirement Aug 29 16:32:12 yeah Aug 29 16:32:28 100uF tant should be fine then Aug 29 16:50:11 they used 100 uF alu, on the wrong side of the power switch :P Aug 29 16:50:31 well thats dumb Aug 29 16:50:35 although it's useful there too, to help keep vsys alive just long enough during sequenced poweroff Aug 29 16:50:46 lol Aug 29 16:50:50 classic Aug 29 16:51:46 it's the fat electrolytic cap you can see near the USB-A connector on the top side (next to the PTC protecting the hdmi 5v) Aug 29 16:52:41 you gotta wonder sometimes who designed this board .. lol Aug 29 16:54:54 *shrug* I'm not quick to judge... there are a LOT of details that can be easily overlooked Aug 29 16:55:04 add some time and money pressure Aug 29 16:57:36 still, it would be interesting to have a simulation of what happens when you have these three in sequence to supply the usb 5v: http://www.mouser.com/ds/2/88/AVE-4653.pdf (100 uF @ 6.3V) -> http://www.ti.com/lit/ds/symlink/tps2041.pdf -> http://www.lairdtech.com/products/li0805h151r-10 Aug 29 16:58:00 and then a device gets plugged in with some nice capacitance Aug 29 17:01:25 zmatt: the usb spec allows quite a dip Aug 29 17:05:47 vsys otoh does not Aug 29 17:06:03 lol prob not Aug 29 17:07:45 and that power switch won't be doing much to stop it either (see its pretty graphs) Aug 29 17:08:50 depends a lot on the internal resistance of your power source Aug 29 17:08:58 there's a power plane isn't there in the board? Aug 29 17:09:09 I doubt vsys is a plane Aug 29 17:09:20 almost nothing uses it directly Aug 29 17:09:21 ah perhaps not Aug 29 17:09:30 it has decent amount of caps Aug 29 17:10:27 * veremit has a quick look Aug 29 17:10:27 ah btw figure 31 of the tps2051 datasheet shows 120 uF + 0.1 uF on the downstream port Aug 29 17:10:41 and 0.1 uF on the power input Aug 29 17:10:49 0.1 is a godo decoupling cap .. sprinkle liberally Aug 29 17:11:45 lol, now I imagine dipping the BBB in a big jar of 0.1 uF cap sprinkles Aug 29 17:12:41 hmmm Aug 29 17:12:53 :) Aug 29 17:23:08 the patch I suggested would even place the cap on the right side of the ferrite bead (between it and the power switch) rather than directly on the connector Aug 29 17:24:40 I think we need a graphic zmatt .. :p Aug 29 17:28:06 just look at the bottom of a BBB ... the usb connector has four through-hole pins neatly in a row near the back of a connector Aug 29 17:28:27 oh wait, there's google images Aug 29 17:33:15 https://gerbil.xs4all.nl/bbb-usb-5v.jpg Aug 29 17:33:28 that's usb 5v Aug 29 17:34:16 left of it is U8 (its power switch) of which pin 1 (dotted) is probably the best ground available nearby Aug 29 17:35:21 oh wait nm Aug 29 17:35:24 what I said earlier Aug 29 17:35:44 it would DUH be on the pin-side of the FB, you'd be soldering onto the pin Aug 29 17:35:47 sorry, brainfail Aug 29 17:37:46 the "right" side would be the right side of FB7 or maybe place it over the power switch itself (pins 6/7/8 are its output pins) Aug 29 17:38:15 seems more hassle, not sure whether it would have tangible benefit over the easy solution Aug 29 17:38:31 >,< Aug 29 17:41:18 zmatt: does that .. heh .. yeah I think I see what yo mean .. the power switch goes through that ferrite .. nice long track there .. Aug 29 17:41:44 fb7 Aug 29 17:42:09 pin, then southeast and east to FB7, then down and backtrack to the left side of U8 Aug 29 17:42:38 also from FB7 through FB8 to Vbus detection input of the am335x Aug 29 17:43:05 so that giant electrolytic on the otehr side .. is which side of the power switch!? Aug 29 17:43:29 C34 Aug 29 17:43:49 it's straight on vsys basically, which feeds the usb power switch and other stuff Aug 29 17:44:00 so where does U8 get its juice from? Aug 29 17:44:12 vsys Aug 29 17:44:29 whicih pins? presumably some combinatino of 1-4 Aug 29 17:44:50 or a pad? Aug 29 17:45:14 2+3 is in Aug 29 17:45:46 yeah that loks right Aug 29 17:45:53 http://www.ti.com/lit/ds/symlink/tps2041.pdf Aug 29 17:46:18 where dd you say a good ground was? Aug 29 17:46:58 well pin 1 of that thing is GND... maybe not the fattest ground available but it's close enough to bridge by a component if you're lucky Aug 29 17:47:32 there's a via by pin1 yeah Aug 29 17:48:19 oh there's a via hidden there.. it just looked like print to me Aug 29 17:48:29 I think its a via Aug 29 17:50:00 unfortunately you might end up coupling noise into the board by bypassing the FB Aug 29 17:50:35 although big caps will do that relatively poorly Aug 29 17:50:37 noise fro usb? Aug 29 17:51:00 fairly unlikely Aug 29 17:51:22 what's P2 on that side btw? Aug 29 17:52:44 or couple noise into usb, dunno... the FB is there for a reason obviously :P (and cables with ferrite beads, etc) Aug 29 17:53:01 P2 ? Aug 29 17:53:10 the set of pads? Aug 29 17:53:22 oh the JTAG header you mean? Aug 29 17:53:37 olk thought so Aug 29 17:53:59 crappy quality pic showing it in action -> https://gerbil.xs4all.nl/barebone.jpg Aug 29 17:54:29 ah smd pin header Aug 29 17:54:45 wondered if you could pogo it .. probably Aug 29 17:55:25 http://www.tincantools.com/images/D/ARM20CTI20_kit_640x640.jpg you can see the connector that's supposed to go there Aug 29 17:57:00 (the tincantools cable otoh is crap... it doesn't plug the hole of pin 6, so you can *still* end up connecting it wrong way around Aug 29 17:57:01 ah Aug 29 17:58:11 and explosing EMU0/1 as solder jumpers is also kinda lame... Aug 29 17:58:31 lol Aug 29 17:58:34 (they ask $39 for the kit depicted btw) Aug 29 17:58:46 that's not dire Aug 29 18:00:55 well it would add more than 40% to the cost of their cheapest jtag debugger Aug 29 18:01:29 while you can get an xds100v2 for $82 at digikey which includes a proper cable Aug 29 18:01:37 still leaves the problem of the connector though Aug 29 18:02:19 or not Aug 29 18:04:17 "you may also be interested in" shows the official samtec connector for $4.47 Aug 29 18:04:40 (at least I think it's the right one, should double-check obviously) Aug 29 18:04:55 getting the non-keyed one and breaking off pin 6 yourself may be cheaper Aug 29 18:07:30 We got XDS V2 JTAG & just soldered a connector on. That was before we knew we didn't need it. But it seems to work and afaik wasn't complicated. Aug 29 18:08:49 having one baord with jtag is always a good thing to have around Just In Case Aug 29 18:12:02 it's funny to browse around the chip in Wait-in-Reset mode... it feels a bit eerie. the SoC works as normal but nothing is happening Aug 29 18:12:43 some tumbleweed blowing across the L3 interconnect Aug 29 18:12:56 Haven't done that 'cause I haven't done any bare metal, and don't know how to get it work with Linux. Aug 29 18:15:19 never tried jtag + linux, although I saw there's even an option to put the PID in the context ID register to allow e.g. hardware breakpoints/watchpoints that only trip (in userspace or kernelspace) in the context of some particular process Aug 29 18:15:38 (that's a kernel config option) Aug 29 18:16:34 My research indicated "it's not possible" but I didn't dig much. I determined it was simpler to do what I needed with logging and stopped JTAG entirely. Aug 29 18:16:45 same option would also be useful in combo with the ETM... still need to play with that Aug 29 18:17:55 for really real-time logging using the STM in combo with the hardware trace port might be useful, but the xds100v2 doesn't support that. (maybe pruss of another bbb could work as a trace receiver though) Aug 29 18:18:33 Could. I didn't need real-time. Aug 29 18:19:05 I could see where real-time might be a nice to have, but I'm muddling along without it. Aug 29 18:20:38 STM is kinda neat... you just write (anywhere) to some page of "memory" and this gets logged to the trace port, optionally with timestamp (depending on whether you write to the upper or lower half of the page) Aug 29 18:21:00 STM is the chip? Aug 29 18:21:16 it has 256 of such channels (one page per channel) and the channel into which data was written is included in the log Aug 29 18:21:19 System Trace Macrocell Aug 29 18:21:24 Ah. Roit. Aug 29 18:21:54 For some reason here on #beagle I thought you were referring to a STM32 uC. It's been one of those daze. Aug 29 18:22:33 so from an application pov you just write your data (either binary or even just sprintf) into that funny page Aug 29 18:22:48 Sweet. Aug 29 18:23:26 without hardware trace receiver however you're limited to the on-chip Embedded Trace Buffer, which has the annoying property that you cannot read it out while trace is enabled Aug 29 18:23:50 so you can only use it to trace in bursts Aug 29 18:23:57 lol That's clever. Aug 29 18:24:04 (fortunately triggerable) Aug 29 18:30:32 iirc it also stops when full instead of acting as a ring buffer, otherwise you could just have let it trace contiuously and use a trigger to stop it to have a log of the events leading up to a detected problem Aug 29 18:31:40 even more annoying, there's apparently a TI-improved version of the ETB which fixes both these issues... but the am335x just has the standard ARM CoreSight one, not the TI-enhanced version :/ Aug 29 18:32:29 ah wait nm it does act as a ring buffer I think Aug 29 18:33:00 That's something. Aug 29 18:37:45 yeah, and it can optionally trace a bit longer after the trigger, so you can position the "trace window" around (or after) the trigger Aug 29 18:37:58 a bit like a scope Aug 29 18:39:33 the encoding used by STM when tracing to ETB however is *bizarre* Aug 29 18:40:26 (in contrast the format when tracing to hardware output is fairly sane, MIPI system trace protocol 1.0) Aug 29 18:41:29 the STM data in ETB needs to be tokenized from end to start and then parsed from start to end Aug 29 18:42:26 (note: it's not an ARM STM) Aug 29 18:44:37 You're way above me here. I'm just enjoying the info. If I should ever need trace I'm ahead of the game. lol Aug 29 18:44:48 using ETM -> ETB trace however is still on my to-do list to be able to genuinely analyze performance of "optimized" loops, especially if they don't perform as well as you'd expect Aug 29 18:45:21 (ETM is the cpu trace generator) Aug 29 18:46:07 Is it another buffer or something else? Aug 29 18:46:29 Seems to me it would be the source of the ETB data. Aug 29 18:48:04 it's a source of trace data yes Aug 29 18:48:35 and triggers Aug 29 18:49:16 and can generally do some crazy shit to set up conditionals (e.g. to restrict trace to areas of interest) Aug 29 18:50:08 That's kinda cool. Aug 29 18:51:13 its output is combined with the stm output (if not tracing to hardware pins) via a trace funnel before ending up at the trace buffer (ETB) Aug 29 18:52:25 Ofc. *tm for more inputs. Duh. Aug 29 18:52:44 on the dm814x/dm816x, which have exactly the same debug subsystem as the am335x, there's also a DSP whose trace output goes into the funnel Aug 29 18:53:08 those are the only three TF inputs afaik Aug 29 18:55:13 note that STM and ETM are very different beasts: STM is just a data logger, it needs to be explicitly fed with data and tracks who/where/when Aug 29 18:56:03 every core can write to STM, and even EDMA Aug 29 18:56:26 and there are some hardware components which can dump info there too, like the statistics collectors of the L3 interconnect Aug 29 18:56:28 Neat. That could have been useful during PRU development. (shrug) I worked around it. Aug 29 18:57:04 the ETM otoh is an integral part of the Cortex-A8 Aug 29 18:59:04 it can do instruction trace and memory access trace (address only, no data trace) Aug 29 19:00:19 it's moreover a crazy box of building blocks to generate trace conditions, and events/triggers e.g. for the ETB or to be counted by the cortex-a8 performance monitoring counters Aug 29 19:00:46 It sounds like a crazy box of blocks. Very cool crazy if one knows how to assemble them. Aug 29 19:06:07 I was once pretty close to having reasonable overview of its tools Aug 29 19:08:46 like it has address matchers (on instruction fetch or data access), some of which also can do (load/store) data value comparisons Aug 29 19:09:16 you can put special (single-cycle) instructions in your code to explicitly notify etm of... stuff Aug 29 19:09:30 it has counters Aug 29 19:09:37 can match on context id Aug 29 19:10:03 four inputs from the cross-trigger interface (and two outputs to it) Aug 29 19:10:42 49 events from the performance monitoring unit (can use two of them at the same time) Aug 29 19:11:52 and can then for example enable trace only when some boolean expression of two of such terms is met Aug 29 19:12:28 It's just hard to get the output. (grin) Aug 29 19:13:20 well not hard, you just need to stop trace for it Aug 29 19:13:54 (you can use one of those two CTI outputs to trigger the ETB to stop logging data, either immediately or after a programmable countdown) Aug 29 19:14:35 I thought the XDS V2 wouldn't use it, so some custom thing is needed. Or a signficantly greater investment in the JTAG device. Aug 29 19:14:49 you don't need any jtag to use etm Aug 29 19:15:05 Oh. I misunderstood then. Aug 29 19:16:27 the debug interconnect is hooked up to the L3 interconnect, it's software-accessible Aug 29 19:17:24 the benefit of jtag is that it can access the debug interconnect without causing L3 traffic that might perhaps influence some types of sensitive measurement Aug 29 19:17:38 Ah. Roit. Aug 29 19:17:40 the downside of jtag is that it's pig slow Aug 29 19:17:45 lol Aug 29 19:19:11 I wouldn't go above 30 MHz if sampling TDO on falling edge, or 15 MHz if sampling TDO on rising edge Aug 29 19:19:26 (the latter is standards-compliant and is what CCS does with the XDS100v2) Aug 29 19:19:37 and there's a LOT of protocol overhead Aug 29 19:22:42 btw you can find the undocumented memory map of the debug interconnect on the "Debug" tab here -> https://goo.gl/UHF2Fy (see the About tab first for relevant notes) Aug 29 19:23:51 Work in progress! Aug 29 19:24:01 indefinitely Aug 29 19:24:02 ;) Aug 29 19:24:56 ohh, I haven't updated the L4FW tab yet... I didn't know yet which firewall on the am335x protected what Aug 29 19:25:02 I do now Aug 29 19:26:56 I like how Google conveniently destroys all right-click functionality in favor of what they think I want. Aug 29 19:28:35 Looks like Good Info! (tm) Aug 29 19:29:40 there, replaced the "?" descriptions of the last four firewalls by the targets they protect (the AES accelerator, the non-existent second AES accelerator, the hash accelerator, and the ADC) Aug 29 21:52:34 Hi forum Aug 29 21:53:33 I am bought a book title "Mastering Embedded Linux Programming" by Chris Simmonds Aug 29 21:55:12 in a u-boot command shell the following command is issue nandecc hw Aug 29 21:55:59 U-Boot# nand erase 280000 400000 Aug 29 21:57:17 but these command don't seems to be recognised. Does U-Boot provide support for the "nand" commands? Aug 29 21:58:21 * jkridner kicks beagleslackbot Aug 29 21:58:39 I see rcn-ee replied in my Slack view, but I don't see it here. Aug 29 21:59:03 onio: there's no NAND on BeagleBone Black unless you buy a cape with NAND on it. Aug 29 21:59:56 ah Aug 29 22:00:17 beagleslackbot: how do I train you? Aug 29 22:00:27 beagleslackbot: help Aug 29 22:01:00 thanks jkridner **** ENDING LOGGING AT Tue Aug 30 02:59:58 2016