**** BEGIN LOGGING AT Mon Oct 26 02:59:59 2015 Oct 26 14:49:29 how to connect the beagle to gtkterm Oct 26 14:49:45 ? Oct 26 15:35:09 #beagle: why can't I address the gpio ports with fortran open commands ? Oct 26 21:17:09 hello? is anyone here? Oct 26 21:17:26 i'm new to using a beaglebone, i could use some help Oct 26 21:22:47 new to beaglebone, i can;t connect beaglebone to internet through usb due to wifi restrictions Oct 26 21:23:11 can i import a library to the beaglebone through sd card? Oct 26 21:41:19 So the USB CDC driver in the beagle bone won't work because you disabled wifi?! Oct 26 21:42:01 * GenTooMan looks puzzled for a bit. "It should be a regular USB net adapter though I am no expert at that." Oct 26 21:46:32 Noob here, who likes to play with lasers and who has a question: Oct 26 21:47:11 i habe a few small lasers, which run at around 3V. i just discovered the analogwrite of beaglebone black Oct 26 21:47:57 can i just connect the PWN pin and play around with the analog value or could this damage the laser/bbb? Oct 26 22:48:33 sigh, why don't people stick around for a bit after asking a question Oct 26 22:49:01 I presume editorial question? :D Oct 26 22:50:09 anyway, time to make tea and attempt to reanimate our primary development BBB which died while in the middle of installing system updates ( http://pastebin.com/4wUtpfDg ) Oct 26 22:51:52 I won't ask if that is serious or not (heheh) :D which reminds me angstrom become yocto .. or something is the same "build your image" system available now for yocto? Or is angstrom still it's own? Oct 26 22:52:07 zmatt.. "people" have the attention span of a flea Oct 26 22:52:27 has any serious research been done on the attention span of a flea? Oct 26 22:52:37 I'm sure there's a PhD somewhere ... Oct 26 22:52:42 important stuff! Oct 26 22:52:47 GenTooMan: well, hopefully it just fails to boot due to the half-finished updates, which included systemd and friends Oct 26 22:53:08 You mean the pounce bite and suck the blood and hop away? Oct 26 22:53:12 lolz .. see what I mean about systemd .. fine when/if it works :P~ Oct 26 22:53:28 refering to flea attention span. Oct 26 22:53:45 veremit: I'm sure other init systems would be perfectly fine being half-installed Oct 26 22:54:18 this is more an argument for Nix rather than one against systemd Oct 26 22:56:19 most importantly, it suggest to me that this isn't really an appropriate way to deal with a transient failure condition (unable to allocate contiguous kernel memory of requested size) in a block device driver (omap_hsmmc): Oct 26 22:56:23 /* FIXME: cleanup */ Oct 26 22:56:25 return -1; Oct 26 22:57:07 Wow... that's really interesting. Oct 26 22:57:24 especially not when said block device driver is commonly used for the root filesystem in embedded systems, which means that the data corruption which is almost certain to occur as a result can easily produce a broken appliance being RMA'd Oct 26 22:58:19 thats like Sony's encryption key on their PS3 system. Oct 26 22:58:50 lol Oct 26 22:59:09 I had a howler when I accidentally ejected a uSD runnnig my RPI ... oops! kernel panic :D Oct 26 22:59:20 right .. food's finally here .. bb Oct 26 22:59:33 eat in peace for now. Oct 26 23:00:01 I should mess with my panda board. Oct 26 23:00:12 yes Oct 26 23:02:00 veremit: it's also asinine that that results in a kernel panic... it should yell loudly you should reinsert the card _now_ and stall any I/O to that device until you do so Oct 26 23:03:41 although I'm not sure what guarantees are still left you don't have random corruption if you cut the power to a card while it's doing writes Oct 26 23:03:57 depends on the quality of the card controller's firmware I guess Oct 26 23:05:03 +2 zmatt Oct 26 23:07:48 also on how badly corners have been cut to improve performance at the expense of robustness... SD will probably be most robust since it's commonly subject to untimely disconnects in the Real World™ (even though you're not supposed to) Oct 26 23:08:25 while eMMC's high-volume market is mobile devices, where they are not subject to eject and very rarely to sudden power loss Oct 26 23:08:30 everyone knows those connectors will be good at 100g vibration zmatt Oct 26 23:10:16 I should mess with my panda board. Oct 26 23:10:18 why? Oct 26 23:10:20 :P Oct 26 23:10:30 for archeological reasons? Oct 26 23:11:34 zmatt I have a 2 beagle board rev C boards too. I don't see playing with those. The PAnda Board ES has 1G of dram and 2 HDMI connectors that's why? :) Oct 26 23:12:15 panda board also has a very dead processor, quite possibly even more so than the omap 3 Oct 26 23:13:46 Wasn't that the one Palm used? Oct 26 23:14:17 maybe you can reverse-engineer the instruction set of the Tesla (C64T) DSP core... it's probably a C64+ subset, but there's no cpu/isa documentation for it and TI's compiler dropped support for it as being an "obsolete target" Oct 26 23:14:21 omap 4 ? Oct 26 23:16:54 They probably never got far out of engineering state with it. The keystone processors are more interesting but I don't have anything with one of those monsters on it. Oct 26 23:17:14 omap 4 got shipped on quite a number of mobile devices still Oct 26 23:17:37 omap 5 was pretty much stillborn Oct 26 23:18:20 and you'll have two C66x DSPs on the x15 Oct 26 23:19:06 Hmmm I guess video decoding could suck in that case. Bummer still I would like to see if the ES works. It's sitting their looking lonely :D Oct 26 23:19:43 I can't even remember if I made a boot image for it yet. Oct 26 23:19:59 I got BBB's instead and "those were too much fun" :D Oct 26 23:20:23 the omap4 still has the benefit that most of it is quite well documented Oct 26 23:20:48 video decoding wouldn't be done by tesla but by IVA-HD Oct 26 23:21:26 which is unfortunately one of the major exceptions to the "quite well documented" Oct 26 23:21:50 but fortunately the same subsystem is on a number of other TI SoCs, including the am572x Oct 26 23:23:07 still, you do need the right firmware blob to load onto Ducati (the dual cortex-m3 subsytem which looks after the video stuff) Oct 26 23:23:58 rcn-ee can probably tell you what's available for it and where to find it Oct 26 23:31:12 seems angstrom dropped it in 2014 sometime however they have images for it. Oct 26 23:31:38 now to find an SD card that isn't filled with crap... :D Oct 26 23:32:23 still, the omap 4 is a dead-end... the E2E forum has been officially closed Oct 26 23:33:05 but but but ... heh Oct 26 23:34:05 which would demotivate me from playing with it.... well... a little bit maybe... possibly Oct 26 23:34:21 Now what would be cool is if TI made an SoC that work with the Adapteva Epihpany set. Oct 26 23:35:16 Anyhow need some cables SD card... brain ... what did I do with my brain this time! (LOL) Oct 26 23:55:06 that was an unpleasantly long list of questions from fsck asking me whether to fix ... Oct 26 23:56:14 well, that boot sure didn't get very far Oct 26 23:56:21 error while loading shared libraries: /lib/arm-linux-gnueabihf/libc.so.6: invalid ELF header Oct 27 00:06:50 is the image being loaded good or is the memory being used toast? you using the eMMC? Oct 27 00:09:40 I probably should have bought the xm instead of the panda's sigh. Oct 27 00:14:21 well the block device driver started dropping data in the middle of a system update which included essential shared libs like libgcc and libc and other essential packages Oct 27 00:15:40 I got the eMMC mounted over USB now so I'm going to try to manually get it into working state again Oct 27 00:16:40 libc being clobbered is slightly inconvenient since that means I also can't chroot into it to reinstall the packages that were part of this update (which should hopefully fix the system) Oct 27 00:17:47 it would be nice if one could boot from ramdisk and temporarily operate from that... Oct 27 00:17:55 ah I had an inkling the panda was freescale .. but its not .. yeah Oct 27 00:18:08 GenTooMan ..uboot does :p Oct 27 00:18:15 sorta Oct 27 00:18:57 zmatt might be able to suggest the baremetal interface :P Oct 27 00:18:58 GenTooMan: I'd run into the same problem: you can't chroot into the rootfs and use dpkg there Oct 27 00:19:07 I mean, filesystem access I already have Oct 27 00:19:33 zmatt .. has it got important data, or can you scrub it? Oct 27 00:20:28 if its a key system, yiou must be able to reproduce it... no? Oct 27 00:20:28 veremit: although I've already offloaded the most important data, I still prefer to give recovery 1 shot before I resort to resetting the system Oct 27 00:21:23 fair enough .. sometimes its just not worth the effort, but I'm sure you're aware .. and you do put in more than the average effort ;) Oct 27 00:21:48 well, that's the point, this was the master copy. normally we regularly rsync this (minus "device identity" files and temporary shit) to a whole farm of devices, but unfortunately for $reasons this hadn't been done in a while Oct 27 00:22:06 ahhhhh... yeah, know that story... Oct 27 00:22:16 the system update was actually done exactly because we were about to rsync them again (to avoid having to rsync *again* after the update) Oct 27 00:22:37 oops! Oct 27 00:23:14 will this .. event .. skew the $reasons going forward?! :) Oct 27 00:23:29 ? Oct 27 00:24:13 thinking the playing out of the 'false economy' argument... Oct 27 00:24:39 also, I haven't actually put much time into recovery yet, mostly been chatting and being randomly distracted Oct 27 00:24:47 lol ok Oct 27 00:25:21 and waiting for dd to finish making a backup copy of the fs just in case fsck would only make things worse Oct 27 00:25:33 *nod* ofc. Oct 27 00:27:58 and browsing kernel source to see who is the person deserving a kick in the nuts for this :P Oct 27 00:28:50 the one using /* FIXME */ as an error-handling strategy is definitely high on the list, although I think the core issue is actually in the edma driver Oct 27 00:38:42 ARM dma should be simple but I have no idea what TI did to the DMA THIS time. Sometimes they do it right sometimes it's totally borked and they hide it. Oct 27 00:38:58 "ARM dma" ? Oct 27 00:39:34 I have no idea what that might be referring to, but there are no DMA engine(s) designed by ARM on this chip Oct 27 00:39:52 I'm talking about EDMA Oct 27 00:40:16 That would mean the dinstinct possibility it could be a bit interesting to use. Oct 27 00:40:43 distinct even. maybe I should change to Typoman. instead. Oct 27 00:40:59 it is interesting to use, but it's a pretty decent DMA engine Oct 27 00:41:09 as usual, the problem is more with the driver than the hardware Oct 27 00:41:26 (usb being a possible exception of that rule) Oct 27 00:41:48 Well USB is the one bus to rule them all! :D Oct 27 00:42:47 I've found TI's description for how to program DMA on their parts often highly obfuscated. Oct 27 00:42:48 the Universal Shitty Bus Oct 27 00:43:19 oh yeah, EDMA documentation is crap. when I made my own header file for it, I renamed pretty much every concept and register to something sensible in the process Oct 27 00:45:03 It's sad because half the value of a component is documentation on how to use it. Oct 27 00:46:58 my biggest complaints with EDMA are some icky irregulatities in the event-related registers (like you can't manually clear a manually set event) and the fact it special-cased length zero transfers in a really weird and inconsistent way Oct 27 00:48:30 and I don't like that they bypass the event queue when it is empty.. going through the queue anyway would have been useful for debugging (since you'd have some overview of recent dma events) Oct 27 00:48:37 usb works .. mostly .. stop whining :p Oct 27 00:48:46 except TI's shitty implementation Oct 27 00:48:53 holy fark what a rip-off Oct 27 00:49:18 well the core isn't TI's Oct 27 00:49:27 no .. I'll let that slide .. Oct 27 00:51:09 it's interesting that the dma is buggy also, that part was copy/pasted from their Keystone processors Oct 27 00:51:42 although there are subtle differences, so possibly they copy/pasted an early dev version or something, or made random changes Oct 27 00:52:28 shoe-horned it in I would imagine Oct 27 00:52:42 although I wonder here too how much is actually driver bugginess... officially nearly all usb-related errata have been fixed in the current hardware revision Oct 27 00:53:31 it's easy enough to fuck up a driver for such a beast though Oct 27 00:54:08 should be a matter of time if the hardware is 90% working and documented appropriately .... Oct 27 00:54:23 and someone who both cares and understands is working on it Oct 27 00:54:47 the TI parts of usbss are publicly documented Oct 27 00:55:54 including the heaps of incredibly obscure low-level knobs / testing registers of the usb phy Oct 27 00:56:45 (which is always a bad sign, since it means they anticipate a need to twiddle those after production to fix issues) Oct 27 01:03:20 you wouldn't have thought those got documented .. Oct 27 01:03:30 but then .. I've never designed silicon nor written drivers .. Oct 27 01:04:07 DFT registers usually aren't... in fact, often they aren't even accessible though the normal register interface Oct 27 01:04:29 the SoC has a whole undocumented subsystem dedicated to DFT (Device Functional Testing) Oct 27 01:05:09 that's why it's worrying that they are exposed in this case... Oct 27 01:06:06 runtime tuning knobs of hardware stuff that normally has only one sensible setting are usually included in case hardware bugs show up that might be worked around using those knobs Oct 27 01:07:01 hence my expectation is that the amount of such knobs present is inversely proportional to the confidence the designers have it'll work right :P Oct 27 01:07:26 lol hmm Oct 27 01:07:34 of course I may just be a bit cynical here Oct 27 01:07:35 I second your thinking .. Oct 27 01:09:01 but, like... "Disable the VBUS debouncer circuit fix" ... why on earth would I want a bit to disable the "VBUS debouncer circuit fix" ?! Oct 27 01:10:38 lol Oct 27 01:10:53 maybe it breaks OTG Oct 27 01:11:15 how??!? Oct 27 01:11:27 well they also have an OTG Session Request Protocol (SRP) AVALID circuit fix Oct 27 01:11:31 along with a bit to disable it Oct 27 01:13:35 but the really fun stuff is still in the usb phy... you should browse them (TRM section 16.5.4) Oct 27 01:14:05 that is seperate from HNP which requires funny VBUS business Oct 27 01:15:00 that vaguely rings a bell... which means I haven't managed to adequately suppress my memories from having read that stuff Oct 27 01:21:39 it uses a pulsing VBUS to signal things Oct 27 01:22:31 the charger protocol is also really nice :P Oct 27 01:23:13 you know pulsing buses ... just sounds odd? Oct 27 01:23:44 it's not a bus, it's the power supply accompanying the bus Oct 27 01:23:52 (now pulsing it makes much more sense, right?) Oct 27 01:24:28 he he he Oct 27 01:24:31 the more complicated you make a design ... the more likely to fail. Oct 27 01:24:53 how else do you decide who's host when you ahve 2 of them plugged in? Oct 27 01:25:03 ID pin Oct 27 01:26:16 how would that work if they are BOTH hosts? Oct 27 01:26:37 the cable has a micro-A end and a micro-B end Oct 27 01:26:47 ID = GND for host Oct 27 01:26:56 so grounding ID still doesn't resolve who's who Oct 27 01:27:09 reminder the ID pin exists in the socket only, it's not a wire in the cable Oct 27 01:27:21 if you use a micro-A to micro-B cable, one end's ID pin will be grounded, the other end not Oct 27 01:28:52 yes otg is meant to be handled by the ID pin Oct 27 01:28:58 HNP was just invented to save the user from having the swap the cable around Oct 27 01:29:35 usb3.5 or 4 or whichever is symmetrical Oct 27 01:29:42 or however you want to call it Oct 27 01:29:52 upside down and back to front :p Oct 27 01:30:28 it's not, since it still requires usb 2 compatibility Oct 27 01:33:33 ah well there is that Oct 27 01:33:45 but it doesn't matter which way you plug it in ;p Oct 27 01:33:58 I wouldn't want to design that kinda interface :/ Oct 27 01:34:01 do they make microA to microB cables? Oct 27 01:36:31 I would assume so, it's the only way to connect OTG devices together Oct 27 01:36:43 (and without it HNP would be utterly pointless) Oct 27 01:38:33 in fact, it is the only standards-compliant cable with a micro-A connector according to the "usb cables matrix" on wikipedia Oct 27 01:52:50 in practice, have you seen micro A's in products? Oct 27 01:56:04 in practice, I have never used otg Oct 27 01:58:08 lol, I guess the market had a difference of opinion with the USB consortium here Oct 27 01:58:16 but then HNP is _completely_ useless Oct 27 01:59:08 except all Beagle USB ports (except for the full size A ones) are OTG Oct 27 01:59:54 do the right magic and things happen Oct 27 02:00:39 actually both ports of the BBB are OTG-capable but neither is configured as such by software iirc Oct 27 02:02:01 in both cases you may run into vbus problems and may need some ugly hack Oct 27 02:31:52 yeah I've seen a hack around to make th otg port into ahost Oct 27 02:32:01 but thats nasty using mini-B as your 'host' lol **** ENDING LOGGING AT Tue Oct 27 02:59:59 2015