**** BEGIN LOGGING AT Mon Mar 20 03:00:01 2017 Mar 20 04:09:49 hmm is execute only memory a possibility on the am335x's? Mar 20 04:20:16 not officially, but the old trick of decohering the iTLB and dTLB should work just fine Mar 20 04:23:25 in case of baremetal applications this can be combined with TLB locking to avoid having to set this up dynamically in a page fault handler Mar 20 04:23:59 (especially if your instruction-side memory map fits entirely in TLB) Mar 20 04:24:42 s/especially // # it's actually a necessary precondition Mar 20 04:26:49 better question is whether you can inform gcc that .text is not readable, but iirc sufficiently recent versions have an option for that Mar 20 04:27:51 hmmm, or not Mar 20 04:28:46 I thought I had read about it somewhere Mar 20 04:35:19 thanks zmatt Mar 20 07:51:11 ohey, I just found the meaning of some badly documented usb-related control module bits in... the omap4430 trm of course Mar 20 07:52:12 :D Mar 20 07:52:31 musb, the "gift" that keeps on giving Mar 20 07:53:33 actually this is phy related instead, which is just as much fun Mar 20 07:53:56 but the control module register has: Mar 20 07:54:11 bit 0 cm_pwrdn "Power down the USB CM PHY" Mar 20 07:54:16 bit 1 otg_pwrdn "Power down the USB OTG PHY" Mar 20 07:54:48 which of course is about as clear as mud Mar 20 07:55:53 but the omap4430 usb chapter explains right away that "USB2PHYCM contains LDO and bandgap for providing voltage reference to USB2PHYCORE module." Mar 20 08:03:33 gm Mar 20 08:04:28 zmatt: deepsleep stuff is really the most frustrating project I had for a long time :-( Mar 20 08:06:23 thinkfat_: I recently brushed the dust off my old dm814x board... playing with prcm is still just as easy and fun as I remember when you have a Forth running from sram :D Mar 20 08:07:15 I still use that baremetal environment whenever I try to understand some lowlevel detail of some other SoC, whenever they happen to be sufficiently similar Mar 20 08:09:36 zmatt: yes, baremetal is quite a good way to understand a platform from ground up. Mar 20 08:10:34 and a lot more robust to playing around than linux is Mar 20 08:10:44 zmatt: totally Mar 20 08:11:10 linux tends to react badly to getting bus errors in kernel space ;) Mar 20 08:11:11 zmatt: especially since linux is quite a good obfuscator when it comes to understanding a complex chip Mar 20 08:11:16 yes Mar 20 08:11:29 "yay" for abstraction Mar 20 08:12:49 Yesteday I noticed that the ti linux kernel pokes reserved values into CLKTRCTRL of all clock domains Mar 20 08:13:01 haha Mar 20 08:13:05 what value? Mar 20 08:13:24 '3', which is hw-sup sleep on other OMAP platforms but "reserved" on am335x Mar 20 08:14:32 ah, yeah, so the main question is why is it listed as reserved Mar 20 08:15:09 I'm guessing it behaves like 0 or 2 Mar 20 08:15:36 the whole dependency matrix for inter-clockdomain relation configuration is missing, so I think there is no point in hw-sup Mar 20 08:16:02 exactly, it's reserved due to being pointless, but evidently has no ill effect Mar 20 08:16:30 presumably Mar 20 08:16:50 if the missing signalling behaved like "it's ok to sleep" at all times, that would have been noticed Mar 20 08:17:08 although... Mar 20 08:17:53 I know some modules do not prevent a sleep transition of their clock domain Mar 20 08:18:26 it might be interesting to check what HW_AUTO does if you have only such modules enabled Mar 20 08:18:43 HW_AUTO? Mar 20 08:18:45 which I'll check for you now, since I've just been playing in forth with exactly such a module Mar 20 08:18:48 CLKTRCTLR=3 Mar 20 08:18:52 ah, right Mar 20 08:22:21 cm 102 mod 4'0002 idle 2 stby 2 Mar 20 08:22:23 cm 103 mod 6'0002 Mar 20 08:22:28 boom Mar 20 08:22:35 setting it to 3 is *not* safe Mar 20 08:22:47 oh :) Mar 20 08:23:10 so it behaves more like sw_sleep on some modules Mar 20 08:23:20 not quite either Mar 20 08:23:30 well Mar 20 08:23:48 yes actually Mar 20 08:24:09 under these conditions anyway Mar 20 08:24:32 since nobody knows how the dependency matrix looks like... Mar 20 08:24:38 the "impicit" one Mar 20 08:24:41 implicit Mar 20 08:25:26 zmatt: do you know what if a mpu wakeup from off leaves a trace in the romcode trace vectors? Mar 20 08:26:01 I mentioned this earlier... trace vectors are used by pubrom, not by secrom Mar 20 08:26:39 zmatt: and wakeup is through secrom? the TRM is not going into any details here Mar 20 08:26:41 secrom only logs to some write-only register in the undocumented interface to DFTSS Mar 20 08:26:53 yes, I mentioned that too. no evidence whatsoever of the resume path in pubrom Mar 20 08:27:15 if it arrived at the public reset vector, it would simply boot rather than resume Mar 20 08:28:05 ok so the null trace vector I see is not contraticting a wakeup... Mar 20 08:28:47 TRM says the resume address is "verified" and if the verification fails it goes into an endless loop, waiting for a watchdog reset Mar 20 08:28:47 try filling that memory with some nonzero value in advance Mar 20 08:28:57 then you can see if it even clears it at all Mar 20 08:29:29 I null it now, before there was leftover content from the last POR Mar 20 08:29:49 it looks like nothing touches the trace area at all Mar 20 08:30:25 what's the resume address that's being used? Mar 20 08:30:41 um some address in OCMC-RAM Mar 20 08:30:45 physical, of course Mar 20 08:31:08 I checked that it's actually written, it's there and points to the resume function Mar 20 08:31:33 actually, doesn't simple suspend already use that vector? Mar 20 08:31:49 you mean, "standby"? Mar 20 08:31:51 yes Mar 20 08:31:54 yes Mar 20 08:31:57 that works for me Mar 20 08:31:59 in linux Mar 20 08:32:06 (never tried deepsleep) Mar 20 08:32:15 it powers off MPU, so it must resume through romcode Mar 20 08:33:05 the difference between DS1 and Standby is mainly the shutdown of the master oscillator Mar 20 08:33:07 iirc last time I tested it was a 4.4.x-ti kernel Mar 20 08:33:38 need to check what I have on my board and then frob the device tree stuff so that it doesn't shut down debugss Mar 20 08:34:04 you could probably fix that yourself via the m3 tap Mar 20 08:34:10 (once the m3 is released from reset) Mar 20 08:34:21 indeed Mar 20 08:43:07 zmatt: any idea how that verification of the resume address looks like? Mar 20 08:53:47 I thought I read somewhere it just means it lies within OCMC ram Mar 20 09:04:03 I wish I had some evidence of the mpu actually starting and executing code Mar 20 09:06:17 so, just checking.. you're using a kernel where standby is known to work but now you want deepsleep1 to work? Mar 20 09:07:29 no, I have a simple microkernel based os that I'm using to experiment with suspend on the am335x Mar 20 09:07:53 currently I'm trying to get standby to work Mar 20 09:08:18 ok Mar 20 09:08:22 since anything involving shutting down the mosc robs me of all debug capabilities Mar 20 09:08:35 right Mar 20 09:12:57 my last idea was about the sram ldo and me violating some setup time before resumeing the mpu, but I'm not putting it in retention, so that should not be a problem Mar 20 09:14:42 maybe grab a working linux standy setup, enter standby, and then dump prcm and control module? then you have some known-good values to consult Mar 20 09:16:40 you should also be able to use icepick controls to extend the mpu reset until you've had the time to reestablish debug (similar to attach-under-reset often used with microcontrollers) Mar 20 09:18:15 indeed Mar 20 09:18:39 there's some bits in the core control that do "WIR" stuff Mar 20 09:19:50 in the tap control, rather Mar 20 09:20:01 but probably in core control, too Mar 20 09:20:18 I agree with that hypothesis Mar 20 09:21:41 but I'm not sure how that would help me. holding the core in reset is fine, but effectively it will then start in secure mode and I cannot debug that Mar 20 09:21:58 neither invasive or non-invasively Mar 20 09:22:26 it will however attach at the first available opportunity Mar 20 09:24:02 true dat... Mar 20 09:25:47 I'll admit that if you find it stuck in secure mode it probably never left secure mode, although there are ways (all of them unlikely) in which it might be possible to enter the resume vector and subsequently reenter secure mode and get stuck there Mar 20 09:26:30 you've checked and double-checked that everything the mpu needs upon resume has been reenabled before powering it back on? Mar 20 09:27:39 and/or check l3 interconnect error logs for evidence of botched accesses by the cortex-a8 Mar 20 09:28:20 interconnect error logs? Mar 20 09:28:35 yes? Mar 20 09:28:40 eh? Mar 20 09:28:43 oh right, not publicly documented for the am335x Mar 20 09:28:47 wait I'll get you a header Mar 20 09:29:36 now that would be neat, checking if the mpu failed because it tried accessing something that is not enabled Mar 20 09:29:50 yes, they're quite useful Mar 20 09:30:29 do you know if a resume leaves any trace in the PRM_RSTST? Mar 20 09:30:50 I would assume so Mar 20 09:30:51 the TRM says that romcode decides by reading this register what was the boot cause Mar 20 09:30:53 eh Mar 20 09:30:56 PRM_MPU_RSTST Mar 20 09:31:04 yes it may very well Mar 20 09:31:35 I don't expect it to leave anything in the device-level PRM_RSTST Mar 20 09:31:43 nor do I expect secure world will check that register Mar 20 09:31:45 eh Mar 20 09:31:55 only two causes documented: EMU and ICEPICK reset Mar 20 09:32:08 *documented* :) Mar 20 09:32:55 icepick I can rule out, EMU I don't know but I assume it would be through writing to DBGPRCR and I'm sure I didn't touch that Mar 20 09:33:57 dunno how reset through DBGPRCR would be registered... I'm pretty sure I've seen mentioned that EMU refers to reset via ICECrusher Mar 20 09:34:33 link in pm Mar 20 09:35:16 (any missing header dependencies can be found in jbang on github) Mar 20 09:41:05 so, the short summary is: for each Agent set agent.err.req_policy and agent.err.resp_policy to LOG Mar 20 09:43:37 then to check for errors: for each Agent check if agent.err.status is nonzero, if so grab a copy of agent.err.raw, write -1 to agent.err.status to clear it, and if it's a request error (bit 1 of status is 0), decode the error using the ReqErr structure Mar 20 09:45:23 checking can be made more efficient by using policy LOGIRQ, set all bits in each FlagCombiner's .flag[0].enabled Mar 20 09:46:03 then you only need to check .flag[0].pending to know if any module there had an error Mar 20 09:54:09 I hope my headers make some sense (note that I only included ti/subarctic/{ctrl,prcm}.h in case they might be useful, they're not relevant for checking for interconnect errors) Mar 20 09:58:26 * zmatt pokes gently in thinkfat_, hopes he didn't die of information overload Mar 20 09:58:33 ;) Mar 20 10:01:15 uh, wut? Mar 20 10:01:19 :-) Mar 20 10:01:22 sorry Mar 20 10:03:08 I got distracted Mar 20 10:03:12 hehe Mar 20 10:03:50 the fw is just one areay, right? and theres a configuration space where you set up the policy for each agent Mar 20 10:04:08 fw is usually not relevant Mar 20 10:04:18 as in, it's all-open by default Mar 20 10:04:37 yes Mar 20 10:05:20 every flexnoc component lives in one of the two configuration spaces ("service networks") for the l3 interconnect, one for l3f and one for l3s Mar 20 10:05:28 addresses are indicates in the header Mar 20 10:05:32 *indicated Mar 20 10:05:50 (by which I mean ti/subarctic/l3.h ) Mar 20 10:06:20 initiator agents have no registers in flexnoc Mar 20 10:06:56 but you can find the list of initiators and their IDs in enum iid6_t Mar 20 10:09:25 firewalls[] is indexed by target id, which is listed in comments after each declared agent, and can also be found in a readonly register of each agent Mar 20 10:12:21 a map of the L3 interconnect can be found in the "L3/Global" tab of https://goo.gl/UHF2Fy (only those rows that list an ID in the Subarctic column are applicable) Mar 20 10:15:49 zmatt: I think initiator Id is also in the TRM, in the tracing chapter Mar 20 10:21:08 ah, looks like I have a nicer table in https://goo.gl/3cleN8 Mar 20 10:21:25 looks like basically EMIF and OCMC 0 FW are interesting Mar 20 10:22:37 if you're trying to debug prcm issues none of the firewalls are interesting Mar 20 10:24:41 aah, yes, misunderstanding Mar 20 10:24:53 now I get the picture Mar 20 10:25:07 I was all the time concentrating on fw not on target agents Mar 20 10:25:15 but the logging is controlled by target agents Mar 20 10:25:31 yes, firewalls have their own logs but non-firewall-related errors won't end up there Mar 20 10:28:07 (firewall errors are additionally logged as l3 response errors, but those are quite uninformative) Mar 20 10:31:16 but nevertheless, ta_emif and ta_ocmc are likely the interesting ones. Mar 20 10:31:37 if you get an L3 response error from an L4 interconnect then you need to check the L4 error logs, but I don't think I have working headers for those yet... (iirc they're adequately documented in e.g. omap4 trm) Mar 20 10:31:52 ta_emif would be odd, rom shouldn't access anything there Mar 20 10:32:23 ta_l4wk_0 is the main candidate actually Mar 20 10:34:56 zmatt: given that I have no introspection into what happens during the mpu resume, it could well be that it already ran through the ocmc ram part of the resume and got stuck elsewhere Mar 20 10:35:21 on the other hand Mar 20 10:36:03 I had the resume function stubbed to a "while(1);" and still wasnt' able to get back control Mar 20 10:38:04 and if the TRM is correct, the standby wakeup of the mpu involves no setup activities from the boot rom whatsoever, only checking for the resume address and jumping into it Mar 20 10:39:31 right Mar 20 10:39:41 it sounds mysterious indeed Mar 20 10:40:15 I don't think secrom has any reason to access ocmc itself though, it probably just checks things like control module registers Mar 20 10:41:06 yup, I don't think it actually checks for a certain signature in ocmc ram, just reads the control module ... Mar 20 10:41:17 okok Mar 20 10:41:30 got an idea Mar 20 10:41:53 might have shot my own foot again Mar 20 10:48:55 I think it might be a good idea if the M3 checked the control module is enabled before resuming the mpu Mar 20 11:00:35 yes Mar 20 11:00:37 :) Mar 20 11:16:25 nope. might have shot one of my limbs, but that was not it Mar 20 12:51:01 zmatt: hum, req_pol and resp_pol default to "LOGIRQ"? Mar 20 13:13:40 ok, I think I got it set up, for now checking ocmc-ram and l4_wk_0, but no errors logged Mar 20 13:20:24 zmatt: no errors on emif, ocmc-ram, l4_wk_0 Mar 20 15:42:17 tbr: are hwmods not represented somewhere in sysfs or debugfs? Mar 20 15:46:10 thinkfat_: hohum? Mar 20 15:46:50 tbr: I'm looking for a way to enable a certain hwmod without patching the kernel Mar 20 15:47:19 not sure Mar 20 15:57:43 tbr: or a way to prevent shutdown of a hwmod during boot... Mar 20 15:58:01 hmmm Mar 20 16:59:30 . Mar 20 17:08:20 thinkfat: there's some property you can set on it iirc Mar 20 17:08:36 there's also a kernel config option to prevent disabling the debug clock, but that's more effort Mar 20 17:43:41 hello community!!! Mar 20 17:44:12 i want to flash my bbb with fedora will bbblfs work?? Mar 20 17:46:54 hi, i have a new beaglebone blue, when i connect to macbook pro and linux laptop it seems to go through boot sequence based on leds, then goes to blue heartbeat, but doesn’t register at all on laptops. dmesg doesn’t say anything, lsusb/system_profiler don’t mention it at all Mar 20 17:47:16 i’ve tried with a few cables, 12v power supply, and powered usb hub. any other ideas or should i return? Mar 20 17:48:37 please share the logs of " ioreg -p IOUSB -l -w 0" Mar 20 17:54:32 @uka_in_ the output of that doesn’t change whether the beaglebone is connected or not Mar 20 17:55:48 newblue: that's odd... Mar 20 18:00:06 yeah. Mar 20 18:00:16 nothing showed on my ubuntu laptop either Mar 20 18:00:37 for lsusb/dmesg.. haven’t tried ioreg there Mar 20 18:01:07 but i’m not hopeful. my guess would be a busted usb connection somehow, where only power is working not data Mar 20 18:51:02 would i contact beaglebone support about this? or just return directly to arrow? Mar 20 19:34:16 this is beaglebone support Mar 20 19:34:26 actually they do have a return thing Mar 20 19:36:45 i see Mar 20 19:47:24 uka_in_: bbblfs should work fine, assuming fedora works at all that is :D Mar 20 19:48:15 uka_in_: more generally, pretty much any arm-based userspace should work if you install a suitable kernel and bootloader. whether it works *well* will vary of course Mar 20 19:52:08 newblue honestly i'd probably return at this point Mar 20 19:52:34 never before heard of just usb not working though Mar 20 19:53:06 i can't tell from that if its hardware or software Mar 20 19:53:20 its really weird to get a new product from them and have something on it be disfunctional because the testing process is rigorous Mar 20 20:16:20 yeah. to be clear, i don’t need to insert a memory card in the bbblue, right? Mar 20 20:16:38 and i use the microusb connection to connect to my laptop, not the full size usb connection on the bbblue Mar 20 20:43:08 Hi newblue, You are correct. Mar 20 20:48:04 Also, I had to apply this patch to get the blinkled.js demo to work. https://github.com/jadonk/bonescript/commit/62a1aadd3bfac536bcef42c3d0f6cd860ae1ac20 Mar 20 23:24:34 Where do I get the kernel source for the BBB debian image? Mar 20 23:24:52 Linux beaglebone 4.4.30-ti-r64 #1 SMP Fri Nov 4 21:23:33 UTC 2016 armv7l GNU/Linux Mar 20 23:27:31 Full source, not headers, I'm trying to follow: http://processors.wiki.ti.com/index.php/PRU_Training:_Hands-on_Labs#LAB_5:_RPMsg_Communication_between_ARM_and_PRU but TI's wiki is pretty fraught with outdates information and links to old versions of things Mar 20 23:29:04 *outdated Mar 20 23:32:35 (I guess a newer version would be fine too? I'm not sure how picky the kernel/devicetree version mapping is. There seems to be dts files for 4.9 in /opt/source/ but I haven't tried them because 4.4 is what I got out of the box Mar 20 23:33:08 and by out of the box I mean off the latest debian image written onto an SD card Mar 20 23:34:07 I tried apt-get source linux-image-`uname -r` but it said there was no source package Mar 21 00:12:28 MagusOTB: the scripts/patches repo used to build the kernels are in github, as well as a tree containing snapshots of the patched kernels for each release Mar 21 00:13:30 https://github.com/RobertCNelson/linux-stable-rcn-ee/tree/4.4.30-ti-r64 is the patched tree for that particular kernel version for example Mar 21 00:14:58 scripts/patches repo? Mar 21 00:15:21 I haven't built a kernel since like version 2.4, so... my knowledge is pretty out of date Mar 21 00:16:08 https://github.com/RobertCNelson/ti-linux-kernel-dev is the build repo for -ti kernels (pick branch according to series, e.g. ti-linux-4.4.y)... though the readme warns that to recreate older tagged releases you should you something called "yakbuild" (with a link) ... no experience with that though Mar 21 00:16:11 but apparently to do anything more than echo-via-rpmsg with the PRU via remoteproc, one has to build a kernel module Mar 21 00:16:20 that sounds silly Mar 21 00:16:45 I mean, by build I mean like, that's where my code goes Mar 21 00:16:50 and yeah, it does, but I'm pretty sure that's how it works Mar 21 00:17:00 if true, that sounds like good reason to shun remoteproc-pru in favor of uio-pruss Mar 21 00:17:29 the remoteproc way is definitely cooler, and comes with a C compiler that targets the PRU Mar 21 00:17:44 and is generally applicable to other co-processor-like-things Mar 21 00:18:00 for me this is more an exercise in "learn how to use remoteproc" than "learn to use the PRU" Mar 21 00:18:06 I already have it working fine with uio Mar 21 00:18:52 but like, remoteproc has been under pretty heavy development for some time and TI hasn't kept their docs up to date at all, so figuring out where to get things and what the right things to get is a nightmare. Mar 21 00:19:52 and basically everything on every mailing list I can find is somewhere between 6 months and 3 years out of date, and the state-of-the-art has moved about all over the place since then, and nobody I can find has gotten much further than "hello world" Mar 21 00:20:31 (and there's so **** may blog posts on how to make hello world by copying and pasting shell scripts that finding anything more on google is tough, if it does exist) Mar 21 00:21:43 MagusOTB: what do you exactly want the PRUs to do ? if you could elaborate a bit ? Mar 21 00:22:05 control stepper motors and WS2812s Mar 21 00:22:08 yes I know other people have done this Mar 21 00:22:21 but that's no fun, and I couldn't get any of them working Mar 21 00:24:02 (I didn't try very hard, I'm more interested in actually learning how to make it go, bolting together other people's code isn't usually my style) Mar 21 00:24:30 and how do you want to communicate with the PRUs ? Mar 21 00:24:37 interrupts/DMA Mar 21 00:25:29 so the rpmsg does that. and it does provieds you with the sysfs entries to communicate through .. Mar 21 00:25:40 ooh, really? Mar 21 00:25:58 that would be perfect, I'd rather not have to muck with kernel modules if I don't have to Mar 21 00:26:06 I have't seen _any_ docs on doing that though? Do you know of any? Mar 21 00:26:38 how did you do the echo-rpmsg thing then ? Mar 21 00:26:49 it just does messages Mar 21 00:27:37 what I'm aiming for is a large persistant DMA framebuffer and rpmsg interrupts for metadata Mar 21 00:27:47 well, PRUs cant really be interrupted. Interrupts are like setting a bit in case of PRUs. Mar 21 00:28:01 yeah, that's what I mean Mar 21 00:28:25 but like, the rpmsg echo example just provides a character device and it seems to slice up what I write into it Mar 21 00:28:35 what I want is something I can mmap() from the host side Mar 21 00:28:40 (or some equivalent) Mar 21 00:30:19 the prboblem with the messaging paradigm is that I need a relatively large chunk of memory accessable to the PRU that holds a framebuffer and can be updated peacemeal Mar 21 00:30:49 with messages, I'd have to copy data out of the message payload into such a region on the PRU side, which could potentially take enough cycles at an inopportune time to mess up timing Mar 21 00:31:59 TI's docs have a lot of "copy this stuff we wrote, **MAGIC**" so it's pretty easy to get really far into them while having no idea what's actually going on :| Mar 21 00:32:53 so there's a pretty good chance my understanding is missing _large_ chunks Mar 21 00:36:55 so I've only seen the character device entries in /dev/rpmsg* that the example provides, and I've got the pinmuxing all fixed so I can use those to do GPIO, but I haven't seen anything about sysfs entries that do other kinds of communication? Mar 21 00:40:03 if there was a way that I could guarantee that payloads wouldn't be split up, pure message passing would be fine, but I need to be able to pass pretty large messages (10s-100s of KB) as single blobs to avoid having to rearrange them on the PRU sude Mar 21 00:40:26 Assuming I can get them through contiguously, the ~40-100cyc latency for out-of-PRU memory reads is fine though. Mar 21 00:45:07 rpmsg is a buffer at its core. It can have ~500 bytes per buffer per kick. Mar 21 00:45:41 * zeekhuge is trying to recall .... Mar 21 00:47:07 is there enough space on PRUs to keep that 100s of KB of data ? Mar 21 00:49:22 oh ! ofc there is ! the scratch pads .... and shared ... Mar 21 00:49:44 * zeekhuge should sleep ... Mar 21 00:51:40 but yet not in 100s Mar 21 00:53:20 yeah, I need a reasonable hunk of shared Mar 21 00:53:33 so this is these are the buffer sizes : http://lxr.free-electrons.com/source/drivers/rpmsg/virtio_rpmsg_bus.c#L143 Mar 21 00:54:19 Ok sweet. I'll check that out, but gotta go cause this coffee shop is closing. If you find anything else I'd appreciate it and I'll see it when I get home Mar 21 00:56:04 MagusOTB: and this is how you will kick the rpmsg-buffer : https://github.com/ZeekHuge/BeagleScope/blob/port_to_4.4.12-ti-r31%2B/examples/kernel_examples/n-blinky/module/rpmsg_pru_parallel_example.c#L93 Mar 21 01:22:33 hello! Mar 21 01:22:57 I just got my beaglebone blue and I was wondering if there are blue specific documentation or resources available? Mar 21 01:24:05 The current tutorials seems to be for the black, and I'd like to know more about accessing the onboard sensors. Also as much as I love js, I'd like to write c/c++/arduino on it, so if anyone has good writeups on how to do that while tethered, I would be eternally greatful! Mar 21 01:58:06 that's a long time Mar 21 02:00:15 zeekhuge: 100s of KB? what? lol no, the scratch pads are 3 x 116 bytes, the shared local ram is 12 KB iirc Mar 21 02:01:59 ddr3 memory is approximately infinite, but slow and non-deterministic to access from PRU (especially reads) **** ENDING LOGGING AT Tue Mar 21 03:00:01 2017