**** BEGIN LOGGING AT Wed Jan 11 03:00:02 2017 Jan 11 07:42:15 hello Jan 11 07:42:24 anyone here? Jan 11 08:26:44 what a silly question, there are over 200 people here Jan 11 08:34:44 zmatt: by chance do you know what is missing in mailine to support suspend/resume on am335x. I'm interested on see this in mainline Jan 11 08:51:52 well it's not just mainline, it's not even working yet in 4.9-ti apparently Jan 11 08:53:33 arch/arm/mach-omap2/sleep33xx.S is notably missing in mainline Jan 11 08:53:45 it is present in 4.9-ti though, so why doesn't it work then... Jan 11 08:55:34 you're obviously not the only one who will want it in mainline, hence I would hope it is work in progress to get it there Jan 11 09:08:23 I hope so ... I saw that latest patches in ML were send on November 2015, so not sure if anyone is taking care to upstream this functionality Jan 11 09:08:29 that's a pity Jan 11 09:10:25 dunno, obviously a vendor will have at least some motivation to get patches into mainline since that means they don't continuously have to forward-port them themselves Jan 11 09:10:45 especially since the kernel is perpetually fast-moving and has no stable APIs internally Jan 11 09:11:41 for out-of-tree patches it's your problem when a change breaks it, once it's in mainline whoever makes changes has the responsibility to fix whatever breaks :) Jan 11 09:13:17 but it doesn't hurt to inquire of course, I'd suggest mailing the linux-omap list with whoever last posted patches in cc Jan 11 09:13:43 do you have a link to the thread? I mean, were there objections? Jan 11 09:14:53 hum, 4.9-ti does have CONFIG_SUSPEND=y Jan 11 09:19:47 latest I see send to mainline is this RFC http://lists.infradead.org/pipermail/linux-arm-kernel/2014-November/306542.html Jan 11 09:23:01 there was no discussion on that list, but I see there was on linux-omap Jan 11 09:23:04 http://linux-omap.vger.kernel.narkive.com/5mxkkUsz/patch-v4-00-11-arm-omap2-am33xx-add-suspend-resume-support Jan 11 09:27:34 right, there is discussion there, though it is two years old Jan 11 09:29:19 yeah but the question is was there some sort of conclusion, or who exactly has a 2-year old todo pending Jan 11 09:31:23 this archive is annoying... I fixed the font to monospace with a user css rule, but they also ruined whitespace Jan 11 09:34:35 "This I can do, I will just need to make a change somewhere..." -- Dave Gerlach Jan 11 09:34:54 sounds like a v6 of the patch series should have been sent but never was Jan 11 09:37:32 oh Jan 11 09:37:55 "As Tony suggested, split up the series and send the wkup_m3 related patches separately" Jan 11 09:38:02 but the wkup_m3 *is* in mainline Jan 11 09:38:06 so that actually happened Jan 11 09:40:03 yep that's in mainline, so is missing the second part Jan 11 09:40:03 i.e. progress has been made more recently than this thread Jan 11 09:42:00 that was... june 2015, a year after this thread Jan 11 09:44:01 yeah as you say, the second part is missing Jan 11 09:44:31 however it's possible they're working on it before resubmitting Jan 11 09:45:21 since, unless it's due to rcn's patches or config, it ain't working in TI's current 4.9 tree :P Jan 11 09:45:38 which would be a good reason to not submit it ;) Jan 11 10:00:52 zmatt: back to the 4.4-ti kernel, I just build latest from ti-linux-kernel-dev (which is 4.4.41-ti-r80.2) and aaargh, fails for me. So looks like I have something different to you Jan 11 10:02:08 hmmm ... maybe that's the reason Jan 11 10:02:12 wkup_m3_ipc 44e11324.wkup_m3_ipc: could not get rproc handle Jan 11 10:02:37 PM: Cannot get wkup_m3_ipc handle Jan 11 10:07:16 any idea how to turn on the sysfs iio interface for analog inputs? Jan 11 10:07:53 /sys/bus/iio Jan 11 10:21:15 eballetbo: no, that's probably just an ordering issue Jan 11 10:21:33 eballetbo: it successfully loads the wkup_m3 firmware later on Jan 11 10:21:59 right is succeeds later Jan 11 10:22:10 s/is/it Jan 11 10:22:34 http://pastebin.com/zarGrghe Jan 11 10:22:48 bashrc: hmm, I'd guess just an overlay to configure and enable tscadc? Jan 11 10:23:45 eballetbo: what build failure are you getting? Jan 11 10:23:54 did you trigger the wakeup from uart0? Jan 11 10:23:59 build failure? Jan 11 10:24:09 oh nm Jan 11 10:24:13 I misread Jan 11 10:24:19 fails how? Jan 11 10:24:27 doesn't wakeup Jan 11 10:24:46 it's starting to sound like that's specific to your device Jan 11 10:24:51 I've never seen wakeup issues Jan 11 10:25:20 either it suspends and wakes up, or it simply rejects the write "mem" to /sys/power/state Jan 11 10:25:40 (depending on which kernel I tried) Jan 11 10:26:24 it suspends but pressing a key in serial terminal doesn't wakeup Jan 11 10:26:26 just checking, the uart via which you're trying to wake it up is uart0 ? Jan 11 10:26:32 yep Jan 11 10:26:35 the debug uart Jan 11 10:27:05 do you use hardware handshake? Jan 11 10:27:44 I think that is disabled, but let me check Jan 11 10:29:10 no hardware handshake Jan 11 10:30:00 bashrc: yeah it seems disabled by default Jan 11 10:30:06 which makes sense Jan 11 10:31:39 is there some way to enable it? Jan 11 10:31:51 eballetbo: you enabled the no_console_suspend option? Jan 11 10:31:56 or whatever it was called Jan 11 10:32:29 bashrc: yeah, via DT (either the main dtb or an overlay) Jan 11 10:32:42 I'd hope a ready-made overlay is included, but I never use overlays myself Jan 11 10:32:58 you tried googling? Jan 11 10:33:07 yes Jan 11 10:35:34 lol, "Yeah, my sanity is a little different.." -- rcn Jan 11 10:36:06 I found at least one reference for enabling it via dtb-rebuilder Jan 11 10:36:26 zmatt: no, just adding now in order to debug. Did you succeed waking up from uart0 in your system? Jan 11 10:36:29 this is rapidly getting ridiculous again Jan 11 10:36:41 eballetbo: yes, always Jan 11 10:37:28 I need to remember to poke rcn or jkridner about this next time I see one of them again Jan 11 10:37:45 things like SPI, ADC etc should have examples that simply work out of the box Jan 11 10:38:34 the adafruit python library apparently manages to enable the adc? Jan 11 10:39:13 https://gist.github.com/pdp7/cf5551d2e925ac3d8f703d0f0e0f9f43#linux-448-ti-r22 Jan 11 10:39:34 so question is what does that ADC.setup() function do Jan 11 10:41:47 bashrc: try: echo BB-ADC >/sys/devices/platform/bone_capemgr/slots Jan 11 10:43:40 zmatt: ok, something wrong on my side then ( http://pastebin.com/c5tFTLaD ) thanks! Jan 11 10:44:07 ok I think that does it Jan 11 10:44:30 bashrc: ok, I'll add it to http://elinux.org/Beagleboard:BeagleBone_Debian_Image_Migration Jan 11 10:45:25 nice Jan 11 10:46:07 also, is there anything comparable to enable PRUs ? Jan 11 10:46:36 check if you see something that sounds promising among /lib/firmware/*.dtbo Jan 11 10:46:55 ok Jan 11 10:47:43 the actual filename of BB-ADC was something like BB-ADC-00A0.dtbo right? (I don't have a standard install on any beaglebone here to check) Jan 11 10:49:04 yes there's a BB-ADC-00A0.dtbo Jan 11 10:49:09 bashrc: there is something like uio_pruss_enable*dtbo iirc Jan 11 10:53:50 strange adc config Jan 11 10:54:33 https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-ADC-00A0.dts#L36-L41 Jan 11 10:55:44 0x16 makes no sense as averaging value, and I have no idea why you'd want to use the minimum sample time but a large open delay Jan 11 11:21:16 eballetbo: ohey, I just compiled a 4.9-ti kernel myself but with custom config that focusses just on the beaglebone (and not e.g. the x15) and now suspend works Jan 11 11:21:41 zmatt, oooooh you're my hero Jan 11 11:22:11 can you send me the packages to test with my bbb? Jan 11 11:22:15 with one error from musb-hdrc, but that might be because I configured usb as module Jan 11 11:23:01 guys, i still didn't figure out how to use GPIO pins as regular user.. any idea??? here is my question http://stackoverflow.com/questions/41586162/access-gpio-on-beaglebone-as-non-root-user Jan 11 11:23:23 nardev: did you see my example udev rules? Jan 11 11:23:38 lo Jan 11 11:24:40 I only grant permission to gpios explicitly exported by DT though, but that's something I did deliberately since access to arbitrary pins *should* be privileged given that you could damage hardware with mistakes Jan 11 11:25:13 zmatt, i did see it , didn't help Jan 11 11:25:21 so for some particular hw setup I configure the pins in DT (name, direction, default level) Jan 11 11:25:42 they get exported at boot and my udev rule will assign permissions and make symlinks Jan 11 11:26:39 zmatt, you would not believe i changed owner and added 777 permission to anything in /dev and /sys but it didn't help :) Jan 11 11:26:46 i was so desperate .. Jan 11 11:26:47 uhh Jan 11 11:28:52 zmatt, interestingly i2c works .. Jan 11 11:28:58 i2c pins Jan 11 11:29:02 that's because that python module is written like garbage Jan 11 11:29:08 or well Jan 11 11:29:13 :( Jan 11 11:29:45 maybe I'm too harsh since I'd do this too if absolutely necessary for performance reasons Jan 11 11:30:07 "this" being mmap()ing /dev/mem Jan 11 11:30:44 :( Jan 11 11:30:55 but /dev/mem access is only permitted as root (regardless of the permissions set on /dev/mem), and that is indeed how it should be Jan 11 11:32:53 zmatt, Jan 11 11:33:06 so.. i should accept the fact that it can't work :D Jan 11 11:33:11 the way i want it to work? Jan 11 11:33:28 no Jan 11 11:34:02 i don't know what to do :( Jan 11 11:34:37 maybe they have good reasons, but accessing gpio in this way should not be done on a whim... especially not changing pin direction, which is not atomic Jan 11 11:35:27 what is this thing? Jan 11 11:35:44 oh wow Jan 11 11:36:00 is this 1wire or such? Jan 11 11:36:55 or is it just similar-but-not-same ? Jan 11 11:36:57 hmm Jan 11 11:38:18 yeah it's 1-wire Jan 11 11:39:00 and those sillybeans at adafruit reimplemented it in userspace instead of using the kernel driver Jan 11 11:39:31 (which also means the communication will randomly fail now and then) Jan 11 11:41:50 zmatt, i didn't dig deeper .. but i'm so sad now :D Jan 11 11:42:07 linux even has a driver for that DHT11/DHT22 sensor Jan 11 11:42:11 it's just simple beaglebone "white" one and termostat sensor.. Jan 11 11:42:33 ah apparently it's not 1-wire given that it's a bitbang driver Jan 11 11:42:50 but regardless, there's a driver :) Jan 11 11:42:58 well, i don't know for that particular driver, i was trying to stay simple.. just grubbed Adafruit lib Jan 11 11:44:02 http://lxr.free-electrons.com/source/Documentation/devicetree/bindings/iio/humidity/dht11.txt Jan 11 11:44:41 yeah, my experience is that adafruit's code is... not that great Jan 11 11:45:13 in this case they overlooked that there's actually a kernel driver for this sensor Jan 11 11:45:34 and instead reimplemented it themselves, badly Jan 11 11:45:35 i believe they pay somebody to write according the the devices they sell Jan 11 11:46:15 which gpio is your sensor connected to? Jan 11 11:46:25 P8_11 Jan 11 11:47:04 gpio 1.13, ok Jan 11 11:47:58 eys Jan 11 11:48:00 yes Jan 11 11:48:04 1_13 Jan 11 11:55:37 nardev: ok I committed an example to https://github.com/mvduin/overlay-utils Jan 11 11:55:47 thnx Jan 11 11:55:51 try: make dht11.dtbo Jan 11 11:55:56 i'm gonna try it now Jan 11 11:56:02 sudo bin/add-overlay dht11.dtbo Jan 11 11:56:27 i'll Jan 11 11:59:56 ok apparently the dht11/dht22 is indeed not a true 1-WireⓇ-compatible device... yay for chinese manufacturers Jan 11 12:04:15 hm, i couldn't build this Jan 11 12:04:37 hmm? Jan 11 12:04:42 what error do you get? Jan 11 12:05:24 dht11.dtsi: file not recognized: File format not recognized Jan 11 12:05:24 collect2: error: ld returned 1 exit status Jan 11 12:05:28 sorry for paste Jan 11 12:06:59 uhh Jan 11 12:07:28 that's the result of typing "make dht11.dtbo" ? Jan 11 12:07:35 i have ssh enabled from outsid... Jan 11 12:07:39 would you.. Jan 11 12:08:04 make: 'dht11.dtbo' is up to date. Jan 11 12:08:26 ok, you built it already I guess? (typing just "make" will build all overlays) Jan 11 12:08:43 well that is what i did first Jan 11 12:08:46 just make Jan 11 12:09:09 then proceed to step 2 :P Jan 11 12:09:19 did that too Jan 11 12:09:39 did it succeed? does anything show in kernel log? Jan 11 12:10:16 huh, last i see in dmesg is related to webcam.. Jan 11 12:10:44 did the add-overlay say it applied the overlay? Jan 11 12:12:32 you can also check lsmod to confirm whether the dht11 driver has been loaded, or just inspect /sys/bus/iio/devices where your sensor should have appeared Jan 11 12:12:43 mkdir: cannot create directory ‘/sys/kernel/config/device-tree/overlays/dht11’: File exists Jan 11 12:12:46 so it's there.. Jan 11 12:12:57 yes you can't add an overlay twice Jan 11 12:13:18 lsmod | grep dth Jan 11 12:13:22 no result.. Jan 11 12:13:44 I'm assuming you meant grep dht Jan 11 12:14:03 omg :D Jan 11 12:14:09 i should have go hiking today Jan 11 12:14:16 dht11 5536 0 Jan 11 12:14:16 industrialio 62863 1 dht11 Jan 11 12:15:08 well then go play with your sensor :) Jan 11 12:15:34 better kick me in my head.. don't know where to start.. to invoke this from c? Jan 11 12:15:34 eballetbo: oh yeah, the deb, sorry got distracted Jan 11 12:16:07 zmatt, btw. what is this overlay-utils Jan 11 12:16:11 nardev: it's an iio device, which nowadays is commonly used for sensors of all sorts Jan 11 12:16:15 you build as you need.. Jan 11 12:16:27 it's some scripts that make building overlays a bit less painful Jan 11 12:17:13 english is obviously not my 1. language.. what doest that mean practically> Jan 11 12:17:41 an overlay is a runtime change to the device tree Jan 11 12:18:10 like.. interface in runtime? Jan 11 12:18:12 they were actually designed primarily to allow CAPEs to work plug&play, but they found more use over time Jan 11 12:18:42 so in this case it simply declared the existence of a new device Jan 11 12:19:08 hence the kernel loaded the appropriate driver Jan 11 12:19:17 all in all... where can i read more about all of that??? Jan 11 12:19:33 btw, how to access this sensor now? Jan 11 12:20:04 I actually don't know much about iio :) but for basic usage you should be able to get a reading from the device via sysfs Jan 11 12:20:12 like I said, check /sys/bus/iio/devices/ Jan 11 12:20:17 your sensor should have appeared there Jan 11 12:20:20 ok ok.. Jan 11 12:21:34 anyway, the official syntax for overlays is much uglier than device tree stuff normally is Jan 11 12:21:43 so I made a script that fixes that :) Jan 11 12:22:18 along with some scripts for loading/unloading overlays via configfs Jan 11 12:22:38 here is what i have https://paste.debian.net/908231/ Jan 11 12:23:08 people more commonly (ab)use bone_capemgr for that, but we have that disabled (we often reuse the two pins it occupies) Jan 11 12:23:38 so read one of the in_* attributes Jan 11 12:24:27 with cat Jan 11 12:24:28 ok Jan 11 12:24:41 for example Jan 11 12:24:46 nothing :D Jan 11 12:24:47 empty Jan 11 12:24:52 maybe it needs some time.. Jan 11 12:25:11 cat: in_temp_input: Connection timed out Jan 11 12:25:19 check kernel log? Jan 11 12:25:47 dht11 humidity_sensor: Only 62 signal edges detected Jan 11 12:25:59 so it's definitely doing something Jan 11 12:26:06 :D Jan 11 12:26:08 :D Jan 11 12:27:45 i tried tail -f Jan 11 12:27:47 tail: error reading ‘in_temp_input’: Connection timed out Jan 11 12:27:47 tail: ‘in_temp_input’ has become accessible Jan 11 12:27:47 tail: error reading ‘in_temp_input’: Connection timed out Jan 11 12:27:53 *tail Jan 11 12:28:01 tail sounds like a bad idea Jan 11 12:28:11 ha ha Jan 11 12:28:11 :D Jan 11 12:28:12 these are not real files Jan 11 12:28:41 as you might have inferred from getting "Connection timed out" from reading it ;) Jan 11 12:28:52 i know i know.. this really needs more time to initialize Jan 11 12:28:58 cat has noting to get there.. Jan 11 12:29:23 well based on your description cat already hangs for some time Jan 11 12:29:59 yes, but you can't make it wait long enough untile the sensor returns something.. Jan 11 12:30:01 :( Jan 11 12:30:02 so I assume that the moment you try to read it it will start the actual bus read Jan 11 12:30:09 cat will wait indefinitely Jan 11 12:30:22 why it exits Jan 11 12:31:13 i tried with python... Jan 11 12:31:13 for y in file_in.readlines(): Jan 11 12:31:13 IOError: [Errno 110] Connection timed out Jan 11 12:31:16 because of the timeout Jan 11 12:31:19 http://lxr.free-electrons.com/source/drivers/iio/humidity/dht11.c#L251 Jan 11 12:31:26 that's also the moment you get the error in kernel log Jan 11 12:33:25 :( btw, i have similar issue with some analog pins... i use 5 of those... :( Jan 11 12:33:39 also can't read them due to permission issue Jan 11 12:33:45 tried similar things ... Jan 11 12:33:49 which is a completely different issue Jan 11 12:33:51 it's some gas sensors.. Jan 11 12:33:59 i understand.. Jan 11 12:34:13 i'm wondering why bb didn't make this bit more approachable Jan 11 12:34:52 would be nice to have some kind of "global" settings for pin extracted to ether some file or some small app Jan 11 12:35:00 I very much agree Jan 11 12:35:01 hello, there are 4 timers, I have one sensor connectec to each, why is it that if I disconnect 3 of them beaglebone receives the signal from the last one in all 4 timers, even the ones left open? Jan 11 12:35:20 a good pin config tool would be extremely useful Jan 11 12:35:54 Ighor: noise/crosstalk. are internal pull-downs or pull-ups enabled? Jan 11 12:36:50 it shouldn't, right? Jan 11 12:37:15 are internal pull-downs or pull-ups enabled? Jan 11 12:37:22 zmatt: np, no hurry, and lunch time, thanks! Jan 11 12:38:34 i guess there is a pullup enabled Jan 11 12:38:41 but how do I shut it? Jan 11 12:39:22 Ighor: internal pull-downs might have better luck suppressing noise pickup, although these are also very weak so depending on your hardware/connection setup they may not be sufficient Jan 11 12:41:47 zmatt, ur's working with bb? Jan 11 12:42:16 Ighor: how are you connecting the sensors to the bbb? are they sharing a cable? Jan 11 12:42:36 nardev: I have no idea what you're asking Jan 11 12:42:52 zmatt: each sensor has it's own cable Jan 11 12:43:23 zmatt: the first go to timer 1, the second to timer 2 and so on Jan 11 12:43:50 zmatt, do you have any professional relation to BeagleBoard.org Foundation? Jan 11 12:43:56 no Jan 11 12:44:01 zmatt: when I euse all 4 together and turn on my system it works fine Jan 11 12:44:11 Ighor: you mean timer 4-7 probably Jan 11 12:44:32 zmatt: yes, sorry Jan 11 12:45:19 zmatt: but if I disconnect 3, for instance, beaglbone receives the same signal from th one left for all timers Jan 11 12:46:17 how long are these cables? Jan 11 12:46:47 though, in general you simply shouldn't leave inputs floating Jan 11 12:47:13 the internal pulls are quite weak and not always sufficient to suppress noise Jan 11 12:48:04 zmatt: they are quite long actually, around 20 meters Jan 11 12:49:02 connecting such long cables directly to a processor pin without any sort of protection is inviting trouble Jan 11 12:49:25 a small rc filter may be a good idea, and esd protection Jan 11 12:49:52 zmatt: Should I use bigger pulls also? Jan 11 12:51:49 if it's considered normal to have no sensor connector then that would be a good idea. but strong cross-talk may also be indicative of cabling problems Jan 11 12:52:08 is it shielded cable? twisted pair? Jan 11 12:53:40 it should be Jan 11 12:54:21 be sure to accompany each signal with a ground (the cable shield / the other wire of the twisted pair) and connect it to the nearest beaglebone ground available (pins 1/2 of P8 are the obvious candidate) Jan 11 12:55:37 otherwise return currents might flow via other signal wires instead (via capacitive coupling) Jan 11 12:55:58 I see Jan 11 12:56:04 will try that Jan 11 12:57:40 if possible, examine the signal at the beaglebone with a scope to see what's going on Jan 11 12:58:01 try to avoid severe overshoot as that may damage the processor in the long run Jan 11 13:00:48 external connections should normally always receive some "hardening" against noise and abuse Jan 11 13:01:12 e.g. ports like usb and hdmi have filters and esd protection already on board Jan 11 13:02:16 the amount of hardening appropriate of course also depends on the application and usage environment of course Jan 11 13:05:18 http://www.digikey.nl/en/articles/techzone/2012/apr/protecting-inputs-in-digital-electronics looks like useful info Jan 11 13:09:07 cool, thank you Jan 11 13:09:15 figure 11 is a nice example of how to make an input robust, of course with 5V replaced by 3.3V and the specific component values tuned for the application Jan 11 13:10:54 (e.g. if you make the capacitor smaller to allow higher-speed signals then the pull-up should be made smaller to suppress noise) Jan 11 13:11:14 pull-up or pull-down, either works Jan 11 13:54:14 zmatt: fyi, I just found this https://github.com/dgerlach/linux-pm/commits/upstream/amx3-suspend-v4.9-rc7 so seems there is some work to upstream what is pending Jan 11 14:35:01 anyone used beagle core Jan 11 16:17:51 HI Jan 11 16:24:46 hi Jan 11 16:25:42 My BBBW(debian 8.6 very recent immage) cant detect and I2c device connected to pins _9_19 and P9_20 Jan 11 16:26:10 I've tried other devices and all of the I2C pins but to no avail Jan 11 16:27:30 Ive been using i2cdetect (I've installed the most recent one) Jan 11 17:06:25 hi all! Jan 11 17:06:37 gm Talorno Jan 11 17:07:21 is there any guide on hardware securing/hardening of the BBB? Like protecting what's on the eMMC, disabling other boot systems, disabling hardware serial and so on, to minimize the risk of stealing of what's inside the memory and various tampering Jan 11 17:08:20 my goal is to "lock" someway the board but being able -in case of necessity- to have access to it Jan 11 17:10:38 hello jkridner :) Jan 11 17:11:33 I'm not aware of any such guide, but you could look at generic Linux drive encryption info. Jan 11 17:13:10 * jkridner reads quickly over https://wiki.archlinux.org/index.php/disk_encryption#Block_device_encryption Jan 11 17:14:44 i thought about it but i don't have a real knowledge of LUKS or similar, but i [probably wrong] assumed that to use that approach you need some scripts that mounts/access deencrypting the drives at boottime Jan 11 17:14:48 not sure if it applies: http://www.makeuseof.com/tag/4-reasons-encrypt-linux-partitions/ Jan 11 17:14:56 so probably some script will contain the password :D Jan 11 17:35:12 jkridner, gotta go but thanks for your time Jan 11 17:36:39 bye all Jan 11 18:06:28 Hello Jan 11 18:37:26 Quick question: whats the raspi config equivalent in Beagle Board Jan 11 18:37:35 ?\\ Jan 11 19:17:24 (quick question does not equate quick answer....) Jan 11 19:17:50 eballetbo: sorry, I fell asleep... :/ Jan 11 19:19:20 zmatt: np Jan 11 19:19:22 :) Jan 11 19:21:00 I'll msg you the link Jan 11 19:21:31 there ya go Jan 11 19:22:08 the deb includes the config file, so that should suffice to be able to rebuild it using rcn's scripts Jan 11 19:22:44 cool, thanks Jan 11 19:23:34 i saw that pm requires a blob firmware, do you know which version are you using? Jan 11 19:25:37 whatever the linux-image-4.9.0-ti-r13.2 tree uses, which is presumably the latest Jan 11 19:25:50 note that that firmware blob is open source too Jan 11 19:26:31 uh oh, ah I see, it's attached to the kernel image Jan 11 19:26:42 expected something in /lib/firmware Jan 11 19:27:34 yeah no in linux config there's an option somewhere to include firmware files into the kernel Jan 11 19:27:37 dunno why that's used Jan 11 19:28:37 * eballetbo runs to eat something bbl Jan 11 19:29:28 especially since the wakeup m3 isn't necessary to have a usable system, you just don't have device power management (and to be honest I think the cortex-a8 could manage way more of that without the wkup-m3 than it currently does) Jan 11 19:56:17 estas ahy? Jan 11 20:29:29 Hello.. New to beaglebone. Needed some help regarding the setting up of it, as I have Debian installed on it. Can someone suggest some good tutorials to begin with? Jan 11 20:31:58 Hello Jan 11 20:33:17 hello Jan 11 20:33:39 I want to contribute to beaglebone.Please help as to where do I get started from ? Jan 11 20:50:34 grep_aar_kash, i guess it depends on what you wanna do with your bbb..... Jan 11 21:24:55 I am currently trying to implement an spi driver. I Also read on the beagle gsoc page that we are supposed to be familiar with cross compilation to get started for gsoc. Any inputs for that part? Jan 11 21:27:44 sounds like a reasonable requirement yes Jan 11 21:29:03 note that you can test cross-compiled binaries even if you don't have an ARM-based system yet, just install qemu-user (assuming your host system is debian or ubuntu) Jan 11 22:11:51 guitarman_: best to stick around after sending a message. hope you check the logs. gsoc might be a good place to get started on ideas for contribution. Jan 12 00:08:49 Hello Jan 12 00:10:53 Has anyone here experience with openbsd on the beagelbone black? Jan 12 01:49:20 how do you get the status of a pin Jan 12 01:57:50 how do you check the status of pin modes with debian image Jan 12 02:29:15 * zmatt sighs **** ENDING LOGGING AT Thu Jan 12 03:00:01 2017