**** BEGIN LOGGING AT Tue Oct 17 03:00:03 2017 Oct 17 03:19:37 Good night everyone. Oct 17 03:20:27 I'm building a little project with a bbb and a gameboy color, but there is an odd problem. Oct 17 03:21:00 My bbb freezes while I'm reading the clock signal from the GBC. Oct 17 03:21:22 It only resume responding when the signal is disconnected. Oct 17 03:22:05 It seems to be related to the pin being set to trigger an interrupt. Oct 17 03:23:26 I'm googling around but not finding anything relevant. Oct 17 03:23:51 Does anyone have a clue what this might be about? Oct 17 03:32:33 It won't freeze when the GPIO edge is set to none. Oct 17 03:34:27 It also does not freeze when setting the pin manually. Oct 17 03:40:51 best guess: it's endlessly triggering the interrupt without getting back to normal? Oct 17 03:40:57 How quick is the clock signal? Oct 17 03:43:56 8 MHz Oct 17 03:44:16 hm. PRU interrupt or ARM interrupt? Oct 17 03:44:57 I don't know, i'm activating it via sysfs Oct 17 03:45:15 /sys/class/gpio/gpioXX/edge Oct 17 03:45:41 setting it to falling, rising, both, none Oct 17 03:46:21 that's an arm interrupt. I think this might be a bit fast for doing it on the ARM side (in scripting?), but what do I know? Oct 17 03:47:38 C++, mmap and sysfs for the interrupts via poll Oct 17 03:48:29 the idea was to read the 16bit address and 8bit data each clock cycle Oct 17 03:48:58 data would be read via mmap but the interrupt to trigger the reading would be using sysfs edge + poll on value Oct 17 03:49:10 okay. Just gonna let you know, I failed to create something that worked at 6 Mhz on a Pi. You might want to consider using the PRUs. Oct 17 03:49:17 and are you just trying to read data? Oct 17 03:49:43 hm, but the number of inputs you want could be an issue.,, Oct 17 03:49:43 read address, write data Oct 17 03:50:07 Are you trying to create a GBC cart emulator? Oct 17 03:50:29 that is it Oct 17 03:52:43 I'm lmao here. Oct 17 03:53:05 https://github.com/kitling/NTRPi Oct 17 03:53:30 tldr I failed at creating a ds cart emulator. Oct 17 03:53:56 but for the Pi. Oct 17 03:54:42 Ain't the DS like, 10x faster? Oct 17 03:55:55 I built a cart reader someone posted on the net, and now I had a GBC without a cat slot, so why not build something to emulate carts also? :-D Oct 17 03:56:03 *cart slot Oct 17 03:56:10 The cart slot runs at 4-6Mhz Oct 17 03:56:27 so, it runs slower, actually. Oct 17 03:57:08 I think your only chance is going to be to use the PRUs, but the issue is going to be the number of inputs. Oct 17 03:57:34 https://dhole.github.io/post/gameboy_cartridge_emu_1/ Oct 17 03:58:21 hm. idk Oct 17 03:59:58 then again, the datel powersaves *does* use a stm32, but it's in master mode. Oct 17 04:00:40 idk. good luck to you. best guess is continuous interrupts, would still reccomend finding a way to fit the PRUs in. Oct 17 04:02:19 Sorry for being pessimestic. Oct 17 04:02:34 zmatt, you here? Oct 17 04:03:17 yow kitlith have you tried fbtft? Oct 17 04:03:25 with bbb Oct 17 04:03:26 No problem, I'll keep trying and eventually get something that can handle the speed. Oct 17 04:03:53 bg08, I've had my beaglebone for less than a week, so no. Oct 17 04:04:08 my bad, thanks anyway Oct 17 04:04:17 no problem! Oct 17 04:04:33 Zeh-GBC, I'm highly amused we both ended up here at the same time. Oct 17 04:04:48 I want you to be able to find a way. Oct 17 04:08:34 Maybe going deeper in the SO, building a driver or something Oct 17 04:09:12 whatever you do, I'd reccomend looking at https://github.com/abhishek-kakkar/BeagleLogic Oct 17 04:09:37 it's, well, it's what got me to buy my beaglebone. Oct 17 04:09:57 I don't know know enough about the PRU, it might as well be the answer. Oct 17 04:10:42 there are some limitations: such as only certain pins being available to the PRUs. and I think each PRU can only control up to 16 pins. Oct 17 04:10:54 If it has shared access to the memory and about 9 pins Oct 17 04:11:38 -- ah, but accessing the dram/regular peripherals is slower. Oct 17 04:11:51 that said, it may be exactly what you need. Oct 17 04:12:28 it only needs to be fast enough to hit that 8 or 4 MHz Oct 17 04:13:57 does the cart run at 8Mhz or at 4Mhz? Oct 17 04:14:38 probably 4 on the GB Oct 17 04:14:48 and they might go up to 8 on the GBC Oct 17 04:15:09 because 4Mhz is possible, even from a Pi running at ~4Mhz. Oct 17 04:15:15 I don't have an oscilloscope to check Oct 17 04:16:20 well, there's this: http://problemkaputt.de/gbatek.htm but it's not the gbc, it's the gba Oct 17 04:18:11 The guy from the article says: "The first thing I noticed is that the CLK is at 1MHz," Oct 17 04:18:15 (drat it where's the stuff talking about clock speeds >_>) Oct 17 04:23:00 well, the research goes on. I'll keep trying. Oct 17 04:26:14 Thanks for the help thou. Oct 17 05:40:12 Kitlith: I will be once I've partaken in some caffeine Oct 17 05:40:18 k! Oct 17 06:04:20 Enough research for today. Got some leads on what to explore next. Oct 17 06:04:34 k! Oct 17 06:19:14 Kitlith: okay... did you have specific questions? Oct 17 06:20:43 not quite yet, just wanted to say that I am getting started with it and undoubtably will. probably will need help talking to the edma controller, but will look at documentation as much as I can. Oct 17 06:21:03 bought a beaglebone green wireless so I have a plan of edio in case this can't work. Oct 17 06:23:43 Kitlith: did I already pass you a link to https://liktaanjeneus.nl/edma3.h.html ? Oct 17 06:24:03 no, I don't think so! Oct 17 06:24:55 it together with edma3-tc.h (note #include is link) are my edma3 headers Oct 17 06:25:47 with imho more sane naming of registers than the official ones, which tend to look like someone just smashed his fists on a keyboard Oct 17 06:25:58 so the only thing in addition needed is the privilidged hack? Oct 17 06:26:55 (which you have already passed me) Oct 17 06:27:32 and you need to make sure that the resources you use are reserved in DT so the kernel driver doesn't try to use them as well Oct 17 06:27:39 lemme look up what I did for that Oct 17 06:29:37 this stull also pulls in defs.h, which pulls in some config stuff... let's see what I can get away with. Oct 17 06:30:08 defs.h is something I use in basically all my code Oct 17 06:30:25 heh, so that's what 'let' is. I think I might just do a let -> auto conversion Oct 17 06:30:40 I was about to say, it explains where "let" comes from ;) Oct 17 06:30:47 yeah Oct 17 06:31:01 lest my custom syntax highlighting fool you into thinking it's a real keyword Oct 17 06:31:27 Yeah I thought it might be a C++14/17 thing or whatever Oct 17 06:31:55 makes sense. Oct 17 06:32:56 trailing return type in function declarations (which, together with auto-declarations of variables motivated me to #define let auto) are a C++11 thing actually Oct 17 06:36:18 yeah Oct 17 06:37:34 you're using uio-pruss I assume? Oct 17 06:39:19 (I currently don't actually have a program written >_>) Oct 17 06:39:40 *really* just getting started, copying in your headers, etc. Oct 17 06:39:48 or intend to use Oct 17 06:40:21 Yeah, probably that + mmap if/when necessary. Oct 17 06:41:14 uio uses mmap too :P (you probably meant "+ /dev/mem when necessary", which is the case for edma) Oct 17 06:41:53 yes Oct 17 06:42:15 you'd mmap /dev/mem in, though, (right?) Oct 17 06:42:40 so, the edma resources you need are dma channels 0 and/or 1, which are the ones that connect to pruss, and one or more "PaRAM slots" ("jobs" in my header) Oct 17 06:42:51 yes Oct 17 06:45:24 ... of course you use u8/u16/u64 instead of uint8_t etc. Oct 17 06:45:30 you're free to use any channel that isn't being used by a driver, but iirc declaring channels in DT has the benefit of also reserving one slot for each (with the same number as the dma channel) Oct 17 06:49:32 you're using a recent image that uses u-boot overlays right? Oct 17 06:49:41 I believe so. Oct 17 06:50:01 verify in your /boot/uEnv.txt that u-boot overlays and uio-pruss are enabled Oct 17 06:53:22 enable_uboot_overlays=1 Oct 17 06:53:38 (and that rproc-pru is disabled) Oct 17 06:54:36 pru_rproc overlay is commented out, pru_uio is commented out (probably because I have beaglelogic also setup) Oct 17 06:54:52 ah Oct 17 06:55:08 beaglelogic uses a custom driver or something like that? Oct 17 06:55:18 it uses a kernel driver, yeah. Oct 17 06:56:13 and a DT overlay to go with it I guess? Oct 17 06:56:27 wouldn't be surprised. Oct 17 06:57:04 well it's relevant to find out since it would conflict with enabling uio-pruss obviously Oct 17 06:57:10 yes it does. Oct 17 06:57:19 (looking at its install script) Oct 17 06:58:12 so you'll need to disable beaglelogic when you're going to play with pruss yourself Oct 17 06:58:25 yup, working on that. Oct 17 06:59:46 let's see, disabled the systemd services, modified uEnv.txt, now I probably need to prevent the kernel module from being loaded... Oct 17 07:00:10 normally kernel modules are loaded automatically Oct 17 07:00:36 disabling the overlay should suffice Oct 17 07:00:54 (you can test that theory by rebooting and checking to see if the kernel module is loaded or not of course) Oct 17 07:02:29 *does package upgrade before reboot* Oct 17 07:02:52 ah, there's that wpa_supplicant update. Oct 17 07:03:30 fortunately wpa_supplicant 2.6 was already immune to the most severe of the attacks Oct 17 07:03:35 "#define NULL nullptr // duh." haha Oct 17 07:04:03 it was? I thought it exasperated one of the attacks by clearing keys to 0? Oct 17 07:04:41 2.6 still clears the keys but rejects their reinstallation Oct 17 07:04:48 ah Oct 17 07:06:48 oh, debian doesn't use 2.6 yet at all Oct 17 07:07:34 kernel module doesn't appear to be loaded. Oct 17 07:09:37 so, I'm not sure how u-boot overlays enables uio-pruss, but presumably simply by loading and applying AM335X-PRU-UIO-00A0.dtbo Oct 17 07:11:00 so, check out https://github.com/beagleboard/bb.org-overlays and verify you can rebuild that dtbo ( make src/arm/AM335X-PRU-UIO-00A0.dtbo ) Oct 17 07:11:53 if that works, add the declaration dmas = <&edma 0 0>, <&edma 1 0>; to the pruss node Oct 17 07:12:22 compile the dtbo, place in /lib/firmware, enable uio-pruss in uEnv.txt if you haven't already, and reboot Oct 17 07:12:52 What is "Cc" Oct 17 07:13:04 ? Oct 17 07:13:15 Cc ? Oct 17 07:13:22 oh, looks like Channel Controller stuff. Oct 17 07:13:44 ah, in my header Oct 17 07:13:56 Cc is the Channel Controller yes Oct 17 07:14:46 yeah, still going through trying to make everything work w/o defs.h (Cc isn't actually the issue, I think offsetof isn't defined atm?) Oct 17 07:14:59 offsetof is a built-in Oct 17 07:15:10 hm Oct 17 07:15:19 what error are you getting? Oct 17 07:16:53 "expected primary-expression before ',' token", "'offsetof' was not declared in this scope", other things not being declared probably because offsetof is failing... Oct 17 07:17:11 (this is at the static_asserts in edma3.h) Oct 17 07:17:36 ah, need stddef.h for offsetof. Oct 17 07:17:40 yes Oct 17 07:18:26 (or officially I guess since this is C++) Oct 17 07:19:05 cast from pointer to uint32_t loses precision... that's just because it's a linter on a 64 bit platform though. Oct 17 07:19:19 indeed Oct 17 07:20:41 also, be advised that I always compile with -fno-strict-aliasing. I don't know if I rely on that in this header specifically, but I do use this assumption freely Oct 17 07:20:53 compiling with -fno-strict-aliasing is better for one's mental health anyway :P Oct 17 07:21:06 it doesn't look like it, I'd be getting warnings about it. Oct 17 07:21:16 it can't always warn Oct 17 07:21:23 oh Oct 17 07:21:33 it will only warn in sufficiently obvious cases Oct 17 07:22:09 such as `*(uint32_t*)bytearray;` Oct 17 07:22:40 bad example, byte-arrays are allowed to alias anything Oct 17 07:22:48 even with -fstrict-aliasing Oct 17 07:22:56 er, right Oct 17 07:24:16 (seem to remember getting a warning about something with that at some point though? eh whatever Oct 17 07:24:20 ) Oct 17 07:24:49 if a compiler could correctly detect aliasing in all cases, it would use that information for optimization and -fstrict-aliasing wouldn't exist in the first palce Oct 17 07:24:52 *place Oct 17 07:25:06 yeah Oct 17 07:26:26 but unless you're trying to get a few % more performance out of some numerical code at the expense of risking your sanity trying to debug the subtle breakage when code violates strict aliasing rules in some non-obvious way... Oct 17 07:27:04 I'd say stick with -fno-strict-aliasing :P Oct 17 07:28:14 yeah Oct 17 07:28:38 yeah, rebuilding that dtb seems to work. Oct 17 07:28:54 so now I just need to add the dmas Oct 17 07:29:27 say, right underneath the interrupts? Oct 17 07:29:35 yeah Oct 17 07:30:45 moved into place... Oct 17 07:31:17 once you've rebooted you can verify that it worked by inspecting /proc/device-tree/ocp/pruss@4a300000 Oct 17 07:32:03 k Oct 17 07:34:04 interesting thing I just realized: `ip addr` only actually needs `ip a` to work. Oct 17 07:34:35 laziness++ Oct 17 07:34:54 the file /proc/device-tree/ocp/pruss@4a300000/dmas exists. Oct 17 07:35:31 doesn't have readable text so I can't say more than that. Oct 17 07:35:34 good! that saves me from having to check the source code to see how u-boot overlays works Oct 17 07:35:37 (laziness++) Oct 17 07:35:42 lmfao Oct 17 07:42:43 hmm, actually it looks like it isn't true anymore that the edma driver reserves slot i for channel i Oct 17 07:42:58 ? Oct 17 07:43:03 so you'll need to reserve some slots too Oct 17 07:43:12 okay Oct 17 07:49:05 that overlay looks needlessly complicated btw, I'm 99% sure it could just be https://pastebin.com/raw/QcTMhwAV Oct 17 07:50:47 adding a reservation for slots would be https://pastebin.com/raw/SrB6fkzV Oct 17 07:52:07 the former looks almost identical to what's already there though? Oct 17 07:52:30 it has an unnecessary level of nesting Oct 17 07:53:01 *meh* Oct 17 07:53:30 the syntax of overlays is still ugly of course Oct 17 07:53:44 that's why I made https://github.com/mvduin/overlay-utils Oct 17 07:53:53 with that makefile you could write https://pastebin.com/raw/4qHqhDZ1 Oct 17 07:55:23 hi, is the fbtft driver already available on the latest image? Oct 17 07:56:53 rebooting after reserving those slots... Oct 17 08:00:25 am I looking for anything in particular in /proc to make sure it's reserved? Oct 17 08:02:38 not really needed, that check was just to verify that you were editing the right file :) but in general, to find where labeled node like &edma resides, search for "edma:" in https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am33xx.dtsi Oct 17 08:02:55 ah, k. Oct 17 08:03:04 i'm fine then Oct 17 08:03:16 { foo { bar { thing: baz {}; }; }; }; means &thing references the node /foo/bar/baz Oct 17 08:03:26 / { foo { bar { thing: baz {}; }; }; }; sorry Oct 17 08:22:07 okay. so now, to get started I want to mmap (a part of?) /dev/mem and use protected writes to talk to the edma controller. Oct 17 08:26:07 and if I understand correctly, I can just map the right area and call it a (Cc*) and it'll all be good. Oct 17 08:26:36 https://gist.github.com/mvduin/30e417d02263ee0fe81ea007f188c5bd Oct 17 08:27:05 (mapping the Cc almost certainly suffices, I just included the Tc declarations for completeness) Oct 17 08:27:40 whelp, that works. Oct 17 08:31:10 for the list of edma channels btw, either see TRM or this spreadsheet I made -> https://goo.gl/7YooOO (when multiple columns are listed, "subarctic" is the am335x) Oct 17 08:51:45 in edma3-tc: "warning: requested alignment 256 is larger than 64" and similar, then a whole bunch of assertion failures on the alignment. Oct 17 08:54:10 ah, that'd be because you override alignas! Oct 17 08:55:02 and it compiles. Oct 17 08:58:18 okay, it's 2 AM, i've got everything setup so I can work on it I guess. g'night. Oct 17 09:01:22 :) Oct 17 09:01:28 nite! Oct 17 09:01:39 the alignment thing is pretty bogus yeah Oct 17 09:01:48 silly gcc Oct 17 10:37:12 Hi everybody ! Oct 17 10:39:35 question about Bonescript. I am running it in console through Node. I am setting "b.digitalWrite(pin, 1)" Oct 17 10:39:40 all fine Oct 17 10:40:09 my question is, how can I see if "pin" is at value "1" o "0" ? Oct 17 10:40:25 the same thing i would do with "cat value" Oct 17 10:40:33 in sysfs Oct 17 10:42:57 digitalRead ? Oct 17 10:43:35 umm, nope, i don't want that because i don't want to transform "pin" into an "input pin" i want to see its output state Oct 17 10:44:12 let me clarify with the procedure i would follow in sysfs Oct 17 10:44:27 does it do that? I don't see anything in the source code suggesting that Oct 17 10:45:13 digitalRead looks up the pin, checks if it's an analog input and handles that case specially, otherwise it calls hw.readGPIOValue Oct 17 10:45:31 hw.readGPIOValue just reads the 'value' attribute in sysfs Oct 17 10:45:31 indeed, i don't find it either in the doc Oct 17 10:46:13 hw.readGPIOValue ... i don't know it, let me check Oct 17 10:46:18 https://github.com/jadonk/bonescript/blob/master/src/index.js#L230-L264 Oct 17 10:46:37 https://github.com/jadonk/bonescript/blob/master/src/hw_universal.js#L148-L164 Oct 17 10:47:15 there are different hw backends. I assume hw_universal is the one being used by default on current images (where cape-universal is enabled by default) Oct 17 10:48:56 You are right ! I misunderstood "digitalRead" ... i was supposing it was changin "direction" to "output" but it does not Oct 17 10:49:22 sorry, to, "input" Oct 17 10:49:44 I am totally new to bonescript;) Oct 17 10:50:01 I don't know anything about it either, I just googled for the source code and checked it Oct 17 10:52:04 Usually i google for docs;P Oct 17 10:53:28 ah, by the way "cape-universal" in Debian 9.2 is not on by default, I need to load it manually Oct 17 10:53:43 Debian IoT Oct 17 10:53:50 hmm, which image are you using? (check /etc/dogtag ) Oct 17 10:54:02 it's been enabled by default for a long time already Oct 17 10:54:15 BeagleBoard.org Debian Image 2017-10-10 Oct 17 10:54:53 that's really weird, that should most definitely have it enabled by default, and even use u-boot overlays... Oct 17 10:55:05 wait, are you running from eMMC or uSD card? Oct 17 10:55:15 SD Oct 17 10:55:53 can you try powering on the BBB while holding down the S2 button? (you can let go as soon as the power led turns on) Oct 17 10:56:25 that forces the use of the bootloader on uSD. by default it will still use the bootloader on eMMC (if one is present) Oct 17 10:56:35 I will surely to the test Oct 17 10:56:48 but i must run out of office immediately Oct 17 10:57:02 In more or less 1h i will be back Oct 17 10:57:05 that will probably fix the problem of cape-universal not being enabled by default Oct 17 10:57:08 ok Oct 17 10:57:28 (if so, a more permanent solution is wiping the bootloader from eMMC) Oct 17 10:57:39 I will tell you later, if u are here, Thank you a lot ! Oct 17 11:44:02 question: i'm trying to work with the PRU and followed the PRU-ICSS 'Resources' page but since i have disabled HDMI(step 3) i can't connect to my BB through wifi... Anyone any ideas? Oct 17 11:48:43 you have beaglebone black wireless I assume? and what page are you referring to? Oct 17 12:14:15 question, i have a BBBwireless and was following followings steps:http://beagleboard.org/pru Oct 17 12:14:36 since step 3, i can't connect through wifi anymore Oct 17 12:24:04 Just tried latest Debian9.1LXQT official image on a Beaglebone White w/LCD7 clone, almost useless as slow it is, some better performances expected by using a black one ? Oct 17 12:47:16 zmatt, i treid what you told me, boot pressing S2, i think univesral has been "loaded" but Oct 17 12:47:56 now i don't have any more the file $SLOTS --> /sys/devices/platform/bone_capemgr/slots Oct 17 13:22:13 overlays are now applied to the device tree by u-boot itself (before the DT is passed to the kernel) rather than at runtime like they were previously Oct 17 13:22:44 didn't know they actually removed capemgr though, I thought it was still around too Oct 17 13:23:12 (presumably overlays can still be loaded via configfs anyway) Oct 17 13:35:43 test, please ignore this line Oct 17 13:43:58 zmatt: so i don't need to export pins on BBB because they are all exported/enabled, is that true? i am running my /dev/mem/ gpio toggle code without export and it still works Oct 17 14:03:46 QUESTION: how can I install capemanager on the BBB wireless?? It's by default on the regular one but not on the wireless Oct 17 14:05:34 zarzar: you can control gpios via /dev/mem as long as the gpio controller is enabled, which is the case if *any* of the 32 gpios of that controller is exported or used by the kernel Oct 17 14:06:39 Guest20939: capemanager isn't something you can install. most likely the difference is not because they're different devices but because they're running different images Oct 17 14:06:42 oh ok Oct 17 14:07:49 Guest20939: it might be the case that cape-manager has been replaced entirely by u-boot overlays in the latest images, but I haven't verified whether this is true Oct 17 14:08:50 Guest20939: if for whatever reason you think you absolutely need capemanager, you can try to see if disabling u-boot overlays works. there's a setting for that in /boot/uEnv.txt which you should comment out Oct 17 14:26:14 I found out that there is a capemanager but it is located a bit differently Oct 17 14:26:41 the problem is that slots isn't the same as with the original beagle bone black Oct 17 14:28:07 have you flashed the same image onto both devices? Oct 17 14:28:22 otherwise any difference is probably just due to different software versions being used Oct 17 14:29:42 like I said earlier, the difference in hardware (bbb vs bbb-wireless) is probably not important Oct 17 14:29:43 but is it even possible to install the exact same images on both devices, due to one working on ethernet and the other one on wifi Oct 17 14:29:50 yes Oct 17 14:30:18 the difference is automatically detected Oct 17 14:31:41 http://bbb.io/latest-images you can see the same image is used for many board variants Oct 17 14:31:51 But on the beaglebone site with the different images, it is said that the image on my BBB is nog fot the BBB wireless Oct 17 14:32:06 which image? Oct 17 14:32:18 the one from 2015 Oct 17 14:33:20 uhhh, well duh that's really really ancient Oct 17 14:33:28 I don't think the bbb-wireless even existed yet Oct 17 14:33:56 yes, i know but that was the default image installed on my BBB Oct 17 14:35:51 okay, well... this is the reason for all differences you're noticing :) a lot has happened since 2015 Oct 17 14:36:58 And i really need the capemanager because i would like to program the PRU's Oct 17 14:37:15 And if i'm right, that the only way tot do it Oct 17 14:37:17 why would you need capemanager for that? Oct 17 14:38:05 because when i find packages i could use, it implements capemanager Oct 17 14:38:14 in the latest images you can enable uio-pruss (or, if you prefer, remoteproc-pru) via /boot/uEnv.txt Oct 17 14:38:25 and you can configure any pins you want using the config-pin utility Oct 17 14:39:54 capemanager itself is not and never has been involved directly in using the PRUs... it was just used to enable the subsystem (whenever it wasn't already enabled by default, this has varied over time) and configure pins Oct 17 14:40:13 both of these tasks have replacements that are easier Oct 17 14:40:44 I'm really new at this and i've been looking on the internet for some examples code, but apparently i've been looking in the wrong direction then? Oct 17 14:40:47 once you enable uio-pruss, using it to work with the PRUs is the same as it's always been Oct 17 14:41:11 I don't know, what have you been looking at? Oct 17 14:41:37 there definitely is a lot of stale info on the web Oct 17 14:42:02 https://github.com/pgmmpk/beaglebone_pru_adc Oct 17 14:42:50 is this the right way then?: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs Oct 17 14:43:33 I've been tying some options the past couple of days, but end up with nothing that works Oct 17 14:44:11 where do you see a reference to capemanager in that github repo ? Oct 17 14:44:44 they use it in the init file Oct 17 14:45:17 ah, I see Oct 17 14:45:31 just disable that code, and make sure uio-pruss is enabled in /boot/uEnv.txt Oct 17 14:47:33 I'm a bit worried by that they seem to directly meddle with the ADC though... that might require unbinding the kernel driver first to make sure it doesn't get horribly confused Oct 17 14:48:31 that wiki page at ti.com uses JTAG, which is extremely inconvenient Oct 17 14:49:04 do you have a site that could guide me through the beginning of programming PRU ( the right way)? Oct 17 14:49:39 I don't have one at hand... never really looked for one Oct 17 14:51:17 I don't want to take advantage of you and your knowledge, but i'm a bit in the dark here. I rather don't try things that could mess up my BBB Oct 17 14:51:57 so i need to avoid JTAGS Oct 17 14:52:09 and avoid cpemanager Oct 17 14:52:12 you never need jtag, you can reflash it simply using an sd card Oct 17 14:52:19 oh, you meant that Oct 17 14:53:04 so, if you find code that enables PRU using capemanager, all you have to do to make it compatible with the latest images is disable those bits of code Oct 17 14:53:26 (and enable uio-pruss in /boot/uEnv.txt) Oct 17 14:54:27 ok thanks you for your help! Oct 17 16:01:02 #devops Oct 17 17:20:21 #c++ Oct 17 17:20:40 why do i do that Oct 17 20:15:57 Hi everyone, I recently purchased a BBB from Adafruit in order to start an at home project and have been unable to get the Adafruit_BBIO_SPI library to function. More specifically, I am being given an error that states "No such file or directory: '/slots/ Oct 17 20:16:47 Would anyone have any idea where to start to fix this issue? I've tried a range of different fixes that I've found online but to no avail. I am new to the world of embedded Linux. Oct 17 20:26:57 (sticking around after asking a question would be a great start) Oct 17 20:32:27 Hi! I'm trying to boot the "official" Debian 8.4 package from debian.beagleboard.org on a Rev C3 Beagleboard. It gets to the point of loading the RAM disk and hangs. Details at https://pastebin.com/KVXF3J3g . Oct 17 20:32:45 Is 8.4 too new for the rev C3 hardware? Or, if 8.4 should work, am I doing something else wrong? Thanks! Oct 17 23:05:00 Repost incoming... Oct 17 23:05:02 Hi! I'm trying to boot the "official" Debian 8.4 package from debian.beagleboard.org on a Rev C3 Beagleboard. It gets to the point of loading the RAM disk and hangs. Details at https://pastebin.com/KVXF3J3g . Oct 17 23:05:06 Is 8.4 too new for the rev C3 hardware? Or, if 8.4 should work, am I doing something else wrong? Thanks! **** ENDING LOGGING AT Wed Oct 18 03:00:00 2017