**** BEGIN LOGGING AT Mon Nov 23 03:00:35 2015 Nov 23 03:02:25 Yes sir. Nov 23 03:02:44 I went to the site. Nov 23 03:02:51 I could not find the software to look it over. Nov 23 03:05:35 I thought it was cape_mgr.*/slots ... Nov 23 03:06:32 eg ... https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay Nov 23 03:06:36 @Set_ Bless your soul. I didn't code it for public consumption. My python script is in the top of this: http://pastebin.com/CHHfY3yk Nov 23 03:07:04 @veremit In my architecture, it's a different directory. Nov 23 03:07:31 uname -a Linux beaglebone 4.1.5-ti-rt-r10 #1 SMP PREEMPT RT Thu Aug 13 22:26:10 UTC 2015 armv7l GNU/Linux Nov 23 03:07:51 it should be similar Nov 23 03:08:14 if there are glaring holes, you got other poblems ;) Nov 23 03:08:20 problems* too Nov 23 03:08:56 check dmesg for errors too Nov 23 03:10:57 @veremit: I've seen the slots in different directories. This tutorial has it in the same place as mine: http://www.embeddedhobbyist.com/2015/09/beaglebone-black-updating-device-tree-files/ But, this tutorial has it in the cape_mgr.*/slots: http://derekmolloy.ie/gpios-on-the-beaglebone-black-using-device-tree-overlays/ Nov 23 03:12:24 ah I suspect it may have moves with the 4.x kernels Nov 23 03:12:40 molloy is likely out-of-date as per usual lol Nov 23 03:13:56 @veremit: dmesg | grep bone_capemgr Nov 23 03:14:23 cape_mgr likely sufficient Nov 23 03:15:43 I didn't know you could 'unload' .. that'shandy Nov 23 03:17:03 I think I was disconnected. Nov 23 03:17:17 I probably missed any posts in the last two minutes or so. Nov 23 03:19:40 @Set_ How's the Python looking? Nov 23 03:19:58 @veremit So, any ideas? Nov 23 03:20:03 I could not find the page. Nov 23 03:21:02 @Set_ Tell me if this doesn't work: http://pastebin.com/kveXHqZ4 Nov 23 03:21:10 Okay. Nov 23 03:21:34 Thanks! Nov 23 03:21:46 Yep...but I cannot promise miracles. Nov 23 03:22:28 Dude. I'm already thankful, no need for miracles. Nov 23 03:23:02 Nope. Nov 23 03:23:08 Did not work. Nov 23 03:23:29 @Set_: Comment out any ADAFRUIT stuff. Nov 23 03:23:43 Well, if you do, then I get working code. Nov 23 03:24:05 With a really sweet signal handler that prints values. Nov 23 03:24:56 I cannot get that order. Nov 23 03:25:52 If you need to know which is Adafruit_BBIO and PyBBIO, I can probably tell you. Is this what you need? Nov 23 03:26:21 http://pastebin.com/0wiCQWTV Nov 23 03:27:05 Okay...I will check this one out too. Nov 23 03:27:06 I need ADC, PWM, GPIO, and SPI capabilities in Python. Nov 23 03:27:11 Oh. Nov 23 03:27:13 Okay. Nov 23 03:27:17 The library I use doesn't matter to me. Nov 23 03:27:43 All things being equal, I'd like to not fool with device trees and whatnot. Nov 23 03:27:45 veremit: you can unload overlays yes... I recommend saving any open files and using 'sync' before you do :P Nov 23 03:28:17 Hello, again, zmatt. Thank you again for your help the other day. Nov 23 03:28:31 you're welcome Nov 23 03:29:05 Device tree stuff is easier. You can go in and change whatever whenever. Nov 23 03:29:38 zmatt :P Nov 23 03:30:00 @Set_:Except in my case. My device tree refuses to change. Nov 23 03:30:07 you're stuck with DT .. unless you go back to Ye Ancient Kernele of Olde Nov 23 03:30:13 note that using bone_capemgr for overlays should be considered deprecated in 4.1 and later (unless they're overlays loaded for actual CAPEs) Nov 23 03:30:53 zmatt: What is the prefered method? Nov 23 03:30:59 zmatt.. how do you do DT on-the-fly then? Nov 23 03:31:00 the configfs mechanism is nicer and doesn't force you to make up bogus metadata for an imaginary cape Nov 23 03:31:26 *Everyone furiously Googles configfs* Nov 23 03:31:29 meh linux is full of fudges :P Nov 23 03:31:40 the configfs mechanism does allow (and ignore) metadata so you can still use the same dtbos Nov 23 03:31:41 BBB especially Nov 23 03:33:03 cd /sys/kernel/config/device-tree/overlays/ Nov 23 03:33:22 make a dir with whatever name you like Nov 23 03:34:00 in it you find a read-only 'status' property (initially 'unapplied') and two writeable properties Nov 23 03:34:26 joe_moquin_.. have you seen https://github.com/graycatlabs/PyBBIO ? looks interesting Nov 23 03:34:42 you can either echo the name of the dtbo to 'path' (resolved relative to /lib/firmware/ I think) or the content of a dtbo to 'dtbo' Nov 23 03:34:55 status will change to 'applied' Nov 23 03:35:03 @veremit: I'm about to plumb those depths right after I finish zmatt's impromptu tutorial. Nov 23 03:35:11 to remove the overlay, just rmdir the directory Nov 23 03:35:34 I gotta say though .. zmatt knows his shit .. Nov 23 03:36:05 Why would I erase a directory on my BBB to import it in a script later? Nov 23 03:36:25 hint: its not a *real* directory .. Nov 23 03:36:44 I believe zmatt actually wrote the book on BeagleBone. Nov 23 03:36:50 this means that if you don't use an actual cape, you can also ditch bone_capemgr which frees up P9.18 + P9.19 which are normally occupied by cape autodetection Nov 23 03:37:03 It is an online version of the directory? Nov 23 03:37:21 zmatt wrote the book on BBB power-up/down sequencing ;) Nov 23 03:37:22 Set_: anything in /sys is magic, they're not real files or real directories Nov 23 03:37:44 Set_: they're just representatives of kernel objects and their properties Nov 23 03:38:00 Okay. Nov 23 03:38:36 normally you can't modify the directory structure in any way (other than changing permissions) Nov 23 03:38:44 zmatt, could you elaborate your earlier comment: you can either echo the name of the dtbo to 'path' (resolved relative to /lib/firmware/ I think) or the content of a dtbo to 'dtbo' Nov 23 03:38:59 i.e. the BASH command Nov 23 03:39:15 echo dtbo > path ? Nov 23 03:39:16 configfs is slightly different because it's meant to provide configuration to the kernel Nov 23 03:39:41 Oh, sorry. I see. Nov 23 03:40:19 Set_: note that sysfs isn't obliged to obey any sort of normal rules of a filesystem Nov 23 03:40:41 (or configfs or debugfs... the umbrella term I think is 'kernfs') Nov 23 03:41:07 zmatt.. I'll go with sysfs .. it matches the name :p Nov 23 03:41:31 veremit: configfs is actually a different fs, it is just current convention to mount it at /sys/kernel/config Nov 23 03:41:55 -shrug- :p Nov 23 03:42:04 although it's slightly more than convention since I don't think sysfs permits you to mount random stuff on top of it Nov 23 03:42:22 but yeah, the distinction isn't hugely important Nov 23 03:42:28 in all cases it's magic Nov 23 03:43:20 ok excuse me folk .. I'ma off to shower :) Nov 23 03:43:27 file sizes are usually nonsense, root can get "permission denied", after creating a dir (when permitted) it's magically populated with stuff, you can remove that dir again dispite being non-empty (in fact you can't remove its contents) Nov 23 03:44:41 Boo! Nov 23 03:44:44 it does obey by *some* rules Nov 23 03:44:54 just not the usual ones Nov 23 03:45:01 Oh. Nov 23 03:45:32 I am getting into the Yocto Project. I want to help them with patches. Nov 23 03:45:50 I am done not knowing much in this realm of cool stuff. Nov 23 03:48:57 veremit: still need to finish that page actually Nov 23 03:50:08 zmatt: Have a little more patience with me. I'm trying to use the configfs route. root@beaglebone:/home/debian# less ADAFRUIT-SPI0-00A0.dtbo > /sys/kernel/config/device-tree/overlays/UCB/dtbo "ADAFRUIT-SPI0-00A0.dtbo" may be a binary file. See it anyway? y Nov 23 03:50:22 joe_moquin_: 'cat' Nov 23 03:50:34 'less' is strictly meant for viewing by humans Nov 23 03:50:47 cat for binary file? Nov 23 03:50:53 eh, yes Nov 23 03:51:06 cat doesn't care what kind of data it's hauling Nov 23 03:51:34 * Set_ Haul "dat" cat you BBB! Nov 23 03:55:12 zmatt: I rmdir the directory, whose dtbo I likely foobared. I mkdir another directory, and used cat to copy the contents of a .dtbo. Should status automatically change to applied if a valid dtbo was moved over? Nov 23 03:56:33 joe_moquin_: note that you can't really mess up the 'dtbo' property... it's not an actual file, when you write data to it it's validated first and if it can't be parsed correctly and applied as an overlay then no effect will take place Nov 23 03:57:37 zmatt: Good. Then, I should assume my passed overlay is invalid. Nov 23 03:57:49 and yes, it should. if it doesn't then something went wrong. since the filesystem API doesn't give much opportunity for detailed error reporting, so errors are reported in the kernel log instead Nov 23 03:59:23 Yep: [ 2276.249094] create_overlay: Failed to resolve tree [ 2466.857868] (NULL device *): Direct firmware load for /home/debian/UCB/ADAFRUIT-SPI0-00A0.dtbo failed with error -2 [ 2685.836211] __of_adjust_tree_phandle_references: Could not find target property 'fixup' @/__local_fixups__ Nov 23 03:59:50 I think that means wrong version of dtc used to compile the overlay Nov 23 04:00:56 Based off the "@"? Nov 23 04:00:56 but I'm not sure, I never really use overlays myself Nov 23 04:01:14 What do you use? Nov 23 04:01:51 based on knowing there's some kind of ABI difference between 3.8.x and 4.1.x overlays, and __local_fixups__ looks like it's supposed to be something magical yet the error message suggests the kernel is treating it like a normal fragment Nov 23 04:02:25 I just compile a custom device tree Nov 23 04:02:28 and reboot Nov 23 04:02:46 more reliable... you never quite know how the kernel will react to runtime changes to the device tree Nov 23 04:03:35 You edit the /boot/uEnv.txt file for this? Nov 23 04:03:55 yes, I set the dtb variable to my own file Nov 23 04:04:31 Man...this AWS sucks eggs. Speakin' of eggs. Nov 23 04:05:05 I have to erase file by file and then the directory. Noooo! Nov 23 04:05:24 zmatt: How do I erase an entire directory with files in it? Nov 23 04:05:33 rm -r Nov 23 04:05:37 I looked it up. What? Nov 23 04:05:40 Serious? Nov 23 04:05:52 -r for 'recursive' Nov 23 04:06:14 You are a life saver, man. Thank you. Nov 23 04:06:23 note that as usual for unix commands, there's no "are you really sure?" :P Nov 23 04:06:50 Oh. Nov 23 04:06:53 it will happily delete the whole content of your home directory for you if you make a typo Nov 23 04:07:01 Hhahahaha. Nov 23 04:07:06 Ooops! Nov 23 04:07:20 so do make sure you aim it at something you really want gone Nov 23 04:07:41 Okay. I am in c9 in /var/lib/cloud9 Nov 23 04:08:08 I have to get rid of the AWS file and directory I put there before I found out that it may or may not work. Nov 23 04:08:09 * zmatt has never used c9 and knows nothing about it Nov 23 04:08:15 Oh. Nov 23 04:08:33 I used it for instruction followings. Nov 23 04:08:50 Yes...plural following. Nov 23 04:09:00 I generally don't follow instructions, occasionally I write them though Nov 23 04:09:22 zmatt: We mere mortals find instructions useful. Nov 23 04:09:39 yeah, that's okay :) Nov 23 04:10:21 but I can't really help with questions about the tutorialy things I never bothered with myself Nov 23 04:11:11 I verified overlays work on 4.1 though, even though I've never used them since Nov 23 04:11:45 You are no liar. Thank you. Nov 23 04:15:03 You are the man dude. I just cleaned up everything that was in memory. Thank you. Point! Nov 23 04:28:05 zmatt: For your dtb= line in /boot/uEnv.txt, where did you place your .dtbo (I assume this is the target, as I'm having a hard time with the documentation)? Nov 23 04:49:40 hi Nov 23 04:57:42 joe_moquin_: dtbo are overlays Nov 23 04:57:50 zmatt: I, again, very much appreciate all you help. Nov 23 04:57:50 dtb= needs to point to a full dtb Nov 23 04:58:13 Yes, I caught that fault right after I posted. Nov 23 04:58:29 they are located in /boot/dtbs/$uname_r/ or /boot/dtbs/ Nov 23 04:58:37 (the first location is searched first) Nov 23 05:01:10 wtf seriously, @#^% incompetent idiots who wrote bootROM Nov 23 05:01:28 after netbooting they leave Ethernet DMA enabled Nov 23 05:02:00 so packet data can still get unexpectedly written to some location in on-chip SRAM Nov 23 05:02:20 Did they leave an explanation as to why it's left enabled? Nov 23 05:03:42 my guess would be "whoops, forgot" Nov 23 05:04:29 I only noticed it because I'm writing a little baremetal tool that systematically scans and maps the L3 interconnect Nov 23 05:04:56 by disabling all targets, poking around, and analyzing the resulting errors Nov 23 05:05:08 and suddenly an unexpected error showed up Nov 23 05:05:24 due to Ethernet DMA attempting to write data to on-chip SRAM Nov 23 05:07:13 Yeah, it sounds like an oversight. That's a nasty bug to have. Nov 23 05:09:59 Does this apply to all modern idevices? Nov 23 05:10:58 dunno, am335x in general, perhaps other devices too Nov 23 05:11:31 now that it's known it's something to watch out for it'll be easy to check which devices are affected Nov 23 05:13:59 yep, problem fixed Nov 23 05:14:16 (by resetting the ethdma early on) Nov 23 05:15:24 time to report it on e2e... Nov 23 05:16:43 oh my, I seem to have a fan... someone started following me on e2e and went on a spree of liking a whole bunch of my posts/comments Nov 23 05:17:37 A welcome surprise, I'd assume. Nov 23 05:28:24 zmatt: yes, yes you should :p Nov 23 05:54:47 Boy! Nov 23 06:02:56 hush :P Nov 23 06:32:43 I am in the Yocto Project's presence. I am trying to configure the system...oops. Nov 23 06:33:14 Second notion, bed time. Yep. Bye for now. Nov 23 06:51:48 hmm yocto. Why. Nov 23 08:10:45 stt_michael: hey, this is an interesting thread, perhaps units affected by the Power Led Blip of Doom can be "rescued" after all... https://e2e.ti.com/support/arm/sitara_arm/f/791/t/469604 Nov 23 08:12:34 someone put an external psu on the 3.3V supply that was being faulted by the pmic... cpu briefly drew 0.5A - 3A and then everything returned to normal, resoldered connection to pmic and the board operated again as if nothing had happened Nov 23 08:13:24 ti techie suspects a protection diode may initially have been damaged by an overvoltage event and caused a low-impedance path to ground Nov 23 08:13:31 yes so I see Nov 23 08:13:43 and burnt the link out .. nice. Nov 23 08:13:47 burn that path to a crisp, problem "solved" XD Nov 23 08:13:54 lol Nov 23 08:14:02 who needs esd diodes anyway Nov 23 08:14:09 pesky things Nov 23 08:14:13 question is .. what ELSE got toasted at the same time ... Nov 23 08:14:22 probably not much Nov 23 08:14:54 most likely it just vapped some trace on the die Nov 23 08:15:43 but since the deep-frying event didn't involve any overvoltage, paths that were not involved in creating the short-circuit were probably unaffected Nov 23 08:15:59 fairly likely Nov 23 08:16:06 as long as it all happened fast enough to avoid the heat from spreading too far Nov 23 08:16:20 yes Nov 23 08:16:40 may want to add some external esd protection though Nov 23 08:16:55 and i suspect warrenty *might* be void Nov 23 08:44:52 lol @ warranty Nov 23 09:51:59 hi guys, anyone know how we can get a bash script to automatically run when we plug a beagle bone black into a PC via USB? Nov 23 09:54:18 prolly an udev rule of some sort Nov 23 09:56:21 ok, tks Nov 23 10:38:09 Hello! Nov 23 10:40:18 Does the beaglebone black come equipped and does it function with free software fully? Nov 23 10:40:30 define "fully" Nov 23 10:41:27 tbr, does it come with proprietary software installed? Nov 23 10:41:40 no Nov 23 10:41:56 it uses u-boot, linux kernel and debian Nov 23 10:42:40 IF you want to have 3D graphics acceleration, then you would need to download and install a driver for the powerVR SGX core Nov 23 10:43:34 tbr, is that proprietary? Nov 23 10:43:44 yes Nov 23 10:44:13 graphics output works just fine without it, just no 3D acceleration for GLES Nov 23 10:51:24 thank you for your answers, tbr Nov 23 10:53:21 so it will work perfectly fine with just open source software Nov 23 11:56:23 note that only the userspace part of sgx is closed Nov 23 11:56:49 the kernel part is MIT/GPL Nov 23 11:56:51 well the kernel module is more of a shim, isn't it? Nov 23 11:57:08 hard to say Nov 23 11:57:15 it's a fair amount of code Nov 23 11:57:26 * tbr admits to never looking closely Nov 23 11:57:35 I knew it was open source though Nov 23 11:57:57 but when I started to examine it I quickly developed a strong urge to gouge my eyes out with a spoon Nov 23 11:58:12 so I chose to discontinue examining it Nov 23 11:58:21 same is said about the sgx source code itself Nov 23 11:58:26 * tbr knows peopleā„¢ Nov 23 12:00:05 woo, first semi-automated scan of the L3 worked Nov 23 12:04:30 only two address ranges I had to manually exclude because attempting to scan them caused a lock-up Nov 23 12:08:37 nice Nov 23 12:15:47 right now it just probes a hardcoded list of addresses, still need to make it automatically determine contiguous ranges Nov 23 12:21:13 http://pastebin.com/LzLV7LCY Nov 23 12:30:17 and need to add more initiators Nov 23 12:30:37 but that's gonna be hard work, each initiator will need its own bit of custom code Nov 23 16:02:55 How can I set my sudo password? Nov 23 16:13:32 you add the user to the sudo group as root Nov 23 16:14:01 Set_: it is your system user's password. If you're using a password-less user (ala ssh), typically you need to setup a NOPASSWD setup in your sudoers Nov 23 16:15:31 i.e. your sudo password is setup by setting up your system user's password by using the passwd command Nov 23 16:16:32 if you are not a sudoer, then you also need to take care of adding yourself as one -- usually by just adding yourself to the sudo group like so: 'adduser your_user sudo' Nov 23 16:16:43 keep in mind, you will need to be root to add a user to a group Nov 23 16:19:07 :D Nov 23 16:22:13 you can check your group membership by using the 'groups' command Nov 23 16:22:28 Okay! Nov 23 16:22:31 Thank you. Nov 23 16:31:15 I tried. Nov 23 16:38:49 can someone tell me the method employed to curate projects at beagleboard.org/projects ? Nov 23 16:39:40 please? Nov 23 16:44:07 Can someone let me know how the projects page is maintained and the methods employed to curate projects? Nov 23 17:38:42 hi all Nov 23 17:39:04 hello singleton Nov 23 17:39:18 I am trying to enable suspendtoRam on 4.1 vanilla kernel Nov 23 17:39:59 I have enabled PM support and firmware image also copied as is required Nov 23 17:40:26 still echo mem > /sys/power/state does not sem to work Nov 23 17:40:57 moreover I am unable to write or read /sys/power/state Nov 23 17:41:19 any idea whether its even possible to use vanilla kernel out of box Nov 23 17:42:45 I am using omap2plus_defconfig and begalebone black dtb present in vanilla kernel Nov 23 17:43:42 any directions from any BBB experts who have tried similiar thing / Nov 23 17:49:23 you'll need to ensure this is enabled in the kernel config Nov 23 17:49:35 for power management stuff you really want a -ti kernel, not a vanilla one Nov 23 17:50:18 any reason why you're specifically using a vanilla kernel? Nov 23 17:55:47 me personally: (vanilla vs ti) because linux-stable doesn't rebase their damn repo :'( Nov 23 17:56:08 also, the state of the device tree in ti is indecipherable Nov 23 17:57:56 I use rcn-ee's ti kernels (which I think follow ti's ti kernels reasonably closely) and my own dtb does work there, albeit with warnings and non-functional power management Nov 23 17:58:27 I still need to give merging the necessary DT stuff for PM a second try, first attempt crashed hard Nov 23 18:00:20 I saw rcn-ee also uploaded a 4.4-rc1-ti-r1 kernel, so that suggests ti finally caught up Nov 23 18:01:19 (assuming it works) Nov 23 18:04:03 Vanilla for simple reason that I can always use the latest and greatest features available... Nov 23 18:05:24 so looks like noone has got latest vanilla working with PM Nov 23 18:05:26 ? Nov 23 18:06:32 you mean TI's kernel is updated with mainline v4.4 ? Nov 23 18:07:05 I do not follow Ti kernels.... so am not aware of conventions they follow Nov 23 18:08:26 where can I find the directions for enabling PM in TI's latest kernel Nov 23 18:08:29 I follow rcn-ee's releases specifically, which are the default kernels on BBB debian Nov 23 18:08:42 ok... Nov 23 18:09:18 there's one difference though in my 4.1 vanilla kernel... i am using a small busybox rootfs... Nov 23 18:09:50 could it be an issue since my /sys/power/state is not r/w Nov 23 18:10:03 I don't think vanilla 4.1 has the necessary code merged in at all, but I'm not sure Nov 23 18:10:41 but I thought /sys/* are vfs and gets mounted by the kernel and no static nodes are needed Nov 23 18:10:45 am i correct ? Nov 23 18:11:02 I have no idea what you're asking Nov 23 18:11:15 'static nodes' ? Nov 23 18:12:23 I mean /sys/power/state file for e.g. is created by kernel on bootup and not like static device nodes like serial console nodes which we need to create through mkdev ... Nov 23 18:13:15 correct, although you shouldn't make static device nodes either usually Nov 23 18:14:02 so do you suggest to use sdk8.0.0 or any other means to enable PM ? Nov 23 18:14:51 or any latest build instructions if you know Nov 23 18:15:12 I just use a standard debian image and suspend to mem works for me Nov 23 18:15:20 *standard BBB debian image Nov 23 18:15:39 I've never used the TI sdk Nov 23 18:16:18 I just tested this on 4.1.13-ti-r33 Nov 23 18:16:55 are there any build instructions about this version 4.1.13-ti-r33 Nov 23 18:17:04 I need the sources Nov 23 18:17:19 yeah, rcn-ee also has his build scripts in github Nov 23 18:18:24 you mean : http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Nov 23 18:18:37 https://eewiki.net/display/linuxonarm/BeagleBone+Black Nov 23 18:19:15 yeah that first page contains links to the built images Nov 23 18:20:12 (avoid the wheezy images btw, if you want to flash a debian system get the latest jessie image, the 'console' one if you want minimalistic) Nov 23 18:21:09 some of the info on that first wiki page is hopelessly outdated btw I just noticed Nov 23 18:22:22 so to build this kernel : Nov 23 18:22:24 git clone https://github.com/RobertCNelson/bb-kernel Nov 23 18:22:41 cd bb-kernel/ Nov 23 18:22:42 that's no the -ti kernel Nov 23 18:22:59 ./build_kernel.sh Nov 23 18:23:04 you'd need the ti-linux-kernel-dev repo Nov 23 18:23:15 ohh ok Nov 23 18:23:44 whats the difference between the two... Nov 23 18:23:58 power management, for one :P Nov 23 18:24:18 the -bone kernels are much closer to mainline, although they still have beaglebone-specific patches Nov 23 18:24:26 (like bone_capemgr) Nov 23 18:25:15 it can be a bit of a maze of info, sorry Nov 23 18:25:27 (of varying degree of outdatedness) Nov 23 18:25:32 WARNING: do not use if you are not use to re-basing git branches.... Nov 23 18:25:52 what's that !!! I must confess I am not a git expert Nov 23 18:26:09 no idea, do you intend to heavily customize the kernel? Nov 23 18:26:42 no... just experimentation purposes Nov 23 18:26:44 (well, I do have an idea, but I don't know what exactly the issue is or how it manifests itself with rcn-ee's git scripts) Nov 23 18:27:36 since worst case you just grab a fresh copy and re-apply your changes and all is well Nov 23 18:27:39 ( http://xkcd.com/1597/ ) Nov 23 18:28:24 thats not an issue... but I still do not get it whats the diff between the "bb-kernel" and "ti-linux-kernel-dev.git" Nov 23 18:28:44 bb-kernel is mainline with some bb-specific patches Nov 23 18:28:46 looks like later is closer to mainline vanilla Nov 23 18:29:10 other way around Nov 23 18:29:16 bb-kernel is closer to mainline Nov 23 18:30:17 otherwise, just try the kernels themselves first on a running debian system, you can just apt-get install and compare them from an operational point of view Nov 23 18:30:54 bb-kernel.git produces the kernels with "-bone" in the name, ti-linux-kernel-dev.git produces the kernels with "-ti" in the name Nov 23 18:31:12 you can also browse the releases here -> https://github.com/RobertCNelson/linux-stable-rcn-ee/releases Nov 23 18:31:52 suspend to mem worked out of the box on 4.1.13-ti-r33 Nov 23 18:32:13 I want to be as close to mainline as possible... at first am looking for PM support, which you seem to have already tested on TI branch Nov 23 18:32:15 right Nov 23 18:32:24 right ? Nov 23 18:32:27 yes Nov 23 18:32:59 out of curiosity... does resume work in this release? Nov 23 18:33:22 I wouldn't say suspend to mem works if resume doesn't :P Nov 23 18:33:22 I saw some posts where suspend works but resume does not seem to work... you need to restart the board Nov 23 18:33:37 yeahh.... lol... Nov 23 18:33:47 but there were some posts abt this issue Nov 23 18:33:49 I woke it up via the console port Nov 23 18:34:06 cool thats what i need for the time being Nov 23 18:34:38 so as you suggested... I'll be using TI kernel Nov 23 18:34:40 the only minor issue was that the leds remained on, but I consider that cosmetic (and would be easy to fix) Nov 23 18:35:19 but one last time... will this kernel have anything missing from bone kernel... I dont care about overlay and capes Nov 23 18:35:46 but any feature missing may be a prob Nov 23 18:35:50 both have support for overlays and capes Nov 23 18:36:06 oops... then whats the diff ;-) Nov 23 18:36:16 power management, for one :P Nov 23 18:36:21 ****confused***** Nov 23 18:36:28 thats a big one Nov 23 18:36:31 and ... Nov 23 18:36:53 and a non-broken LCDC driver (dunno if the fixes have finally been mainlined or not) Nov 23 18:37:29 broken in which one... TI or Bone? Nov 23 18:37:40 mainline / bone, unless it has been fixed Nov 23 18:37:52 clock calculation fucks up about 50% of the time Nov 23 18:38:25 thats means TI kernel has a fix for these issues ? Nov 23 18:38:29 yes Nov 23 18:38:44 then good... i am gonna use that Nov 23 18:38:45 in general TI will be ahead of mainline with regard to TI-specific drivers and stuff Nov 23 18:39:03 got it Nov 23 18:40:36 donno how long you'll be around... am gonna start cloning now... depending on how easily can I get debian over nfs working will post results Nov 23 18:41:04 why not take the easy way first? :P Nov 23 18:41:52 prob is that I have vanilla 4.1 image but busybox over nfs... Nov 23 18:42:24 have used debian only initially some 1yr back Nov 23 18:42:37 so cant just upgrade kernel Nov 23 18:42:43 i'm totally new to beaglebone, but i was hoping that someone could help me with some hardware-releated questions to see if it is a good fit for my application Nov 23 18:42:45 why not just reflash eMMC with a normal debian system to play around with first? Nov 23 18:43:56 I have forgot that stuff... actually i have not used my bbb for last one year :-( forgot all instructions on emmc flash Nov 23 18:44:23 it had uboot from last time i used... so easiest was tftp and nfs Nov 23 18:44:26 setup Nov 23 18:44:42 download flasher, dd it to uSD card, boot the beaglebone from it, wait until it's done flashing :P Nov 23 18:45:27 i am trying to connect to a J1939/canbus system, and I am not clear whether or not i need a cape. It looks like the BBB has canbus support on the board, so why would I need a shield? ( i've seen some available?) Nov 23 18:45:45 you need a transceiver Nov 23 18:46:13 if i use the BBB and the shield, would I then have full capabilities for canbus send/receive at high rates? Nov 23 18:46:16 ok that brings me to another question... do I have debian FS image which can be used as FS over nfs ? Nov 23 18:46:31 surely .img I can not use Nov 23 18:46:49 I have no idea what's on the shield, you can also just use a separate transceiver if you're handy with electronics Nov 23 18:50:27 * zmatt is afk Nov 23 20:03:15 @zmatt : Is it normal while building the TI kernel... menuconfig pops up... I just saved the .config and exited it... Nov 23 20:03:23 should be fine right ? Nov 23 20:13:05 hi, any beaglebone green users? Nov 23 20:13:16 I need some help with Grove I2C, adresses and all Nov 23 20:13:54 none of the grove components I have has default I2C address written on it Nov 23 20:14:09 how do I communicate with devices ? Nov 23 20:14:53 confused: if you're looking to discover the address of unknown i2c devices, checkout i2cdetect: http://manpages.ubuntu.com/manpages/hardy/man8/i2cdetect.8.html Nov 23 20:16:06 tried that, usigng i2cdetect -y -r (1 and 0) Nov 23 20:16:22 however nothing showed up Nov 23 20:16:43 actually, this showes up all the time (whether or not something is connected) Nov 23 20:16:44 50: -- -- -- -- UU UU UU UU -- -- -- -- -- -- -- -- Nov 23 20:17:13 however, no matter what I connect nothing showes up Nov 23 20:17:44 U just means that the kernel has already claimed that address Nov 23 20:18:16 which *might* also mean that the device has been bound to a driver, but that isn't always the case Nov 23 20:18:58 I'd recommend going through your hardware set, and trying out the simplest possible setup, and going from there Nov 23 20:19:08 yeah, I am already there Nov 23 20:19:19 desperate already, that is why I try this chat Nov 23 20:19:33 I have only 1 device connected now. Just simple relay Nov 23 20:21:37 confused1: ideally the only unknown would be the bbg. If you're comfortable with arduino and have the hardware, that is usually the simplest way to prove things out. Nov 23 20:22:51 unfortunatly no, only thing I got around is this beaglebone green Nov 23 20:23:19 strange thing is that i2cdetect -y -r 1 detects nothing Nov 23 20:23:22 the unfortunate truth is that any network of devices is very complicated -- doubly so when attempting to troubleshoot via chat. You need to eliminate as many variables as possible to have a chance here, or anywhere else online Nov 23 20:23:49 unfortunately that could mean a million things given the info that is available. Nov 23 20:24:48 from a hardware issue (your i2c device, or i2c physical network) to firmware/configuration on the bbg (device tree/kernel/userspace programs) Nov 23 20:26:10 sorry :( Nov 23 20:29:15 how to explain that python code to control relay works? via Adafruit_BBIO.GPIO library Nov 23 20:29:37 relay is actually working, but not detected by i2cdetect Nov 23 20:29:37 <[Butch]> Quick question: Apply power to BBB (either USB or 5V barrel connector). Power light flashes for like 1/20sec, no other lights. Nothing. Thoughts? Nov 23 20:31:15 confused1: structure some facts about your problem, and post them to pastebin -- they will go along way in helper people here help you Nov 23 20:32:04 ok, will ask first @ seeed forums (the creators of bbg) Nov 23 20:38:31 confused1: they may have better context -- but you still may consider structuring and outlining your problem. Consider taking the time to understand this article: http://www.catb.org/esr/faqs/smart-questions.html#intro Nov 23 20:40:16 :) Nov 23 20:40:47 I am a bit longer in this space than you might think, I have skiped the introduction here as I though you will catch on instantly Nov 23 20:52:58 [Butch]: the dreaded Power Led Blip of Doom Nov 23 20:53:39 <[Butch]> zmatt: Toast? Nov 23 20:53:45 [Butch]: assuming no external hardware is connected that might be causing an overcurrent fault, it's RMA time Nov 23 20:54:01 <[Butch]> zmatt: Nothing other than power. :-( Nov 23 20:54:24 <[Butch]> zmatt: Tanks for the info. Nov 23 20:54:57 well, someone on e2e accidently found a novel "solution"... as part of debugging the fault they used an external psu instead of the pmic for the supply that faulted Nov 23 20:55:28 caused a brief 0.5A - 3A surge, then everything returned to normal and the chip worked again, including when the supply was connected back to the pmic Nov 23 20:55:51 most likely with a few ESD protection diodes less than he had before Nov 23 20:56:17 or whatever damaged component was causing the short-circuit internal to the CPU and had now been vaporized Nov 23 20:57:50 we still have a similarly dead BBB at the office that I want to try this method on just for fun... frying a chip back to life, quite a novel concept Nov 23 20:58:37 (I put a post-it "dead - RMA" on it like half a year ago and it has made no motion on its own volition towards being RMA'd, so, what the heck) Nov 23 22:06:08 @zmatt: I seem to have a boot issue with this 4.1.13-ti-r33 !!!!! Nov 23 22:07:19 I took zImage and the am335x-boneblack.dtb.... kernel does not even boot Nov 23 22:08:46 I just replaced the zImage and .dtb in my otherwise working setup of vanilla 4.1 Nov 23 22:10:25 there are no serial logs also after "starting kernel..." that means something bad Nov 23 22:10:32 too bad :-( Nov 23 23:25:26 Does anyone know if there is testing information published for the BeagleBone Black and where I could find it? My company is looking at spinning up production with a different manufacturer to create a redundant supply chain. Nov 24 00:29:45 arrrggggggg ACPI tables are worse then HID descriptors Nov 24 01:47:10 Hello? Nov 24 01:54:04 Has anyone encountered issues using the Beaglebone PWM and ADC simultaneously? I am attempting to use the PRU's to drive a motor system and measure the output voltage. Individually the PWM and ADC with the PRU's work fine. Together though the ADC reading freezes on a value. **** ENDING LOGGING AT Tue Nov 24 03:00:52 2015