**** BEGIN LOGGING AT Sun Dec 25 03:00:00 2016 Dec 25 03:11:03 Hello. I seem to be having some trouble running gcc on a beagle bone black running rt patched ubuntu 16.04 Dec 25 03:12:46 Whenever i try running gcc -v or g++ -v, it simply says "command not found" in both cases. Running apt-get install gcc does nothing (package not found_, and running apt-get install g++ gives a large output that ends in 0 of 0 packages changed Dec 25 03:13:31 that sounds pretty weird Dec 25 03:13:45 it looks like make isnt installed either Dec 25 03:14:12 so you're not having trouble running gcc, you're having trouble installing it Dec 25 03:14:28 what's the output of apt-get update ? Dec 25 03:14:47 I suppose so, yes. Although im under the assumption that gcc is installed but something is messwed up configuration wise Dec 25 03:15:05 Looks like everything is updating Dec 25 03:15:45 oh wow Dec 25 03:16:15 Welp, apt-get install gcc works now. I feel like a chump. Thanks a ton for the help! Dec 25 03:16:21 lol Dec 25 03:17:29 yes, you need to do apt-get update once in a while before installing/upgrading packages, e.g. run it unless you've already run it today Dec 25 03:18:06 I just assumed that would happen automatically, guess not then Dec 25 03:18:11 I think on desktop systems there's often some rules installed to do this periodically, but that would probably be undesirable on an embedded system Dec 25 03:18:32 Yeah, i think thats what did me in, assuming im on desktop linux Dec 25 03:19:33 I must say, an rt-patched Ubuntu sounds really strange to me Dec 25 03:20:56 ugh, dont get me started Dec 25 03:21:08 Client gets what the client wants Dec 25 03:24:27 I've actually got another question concerning rt. Lets say I want to do i2c communication from an RT thread, can I just write to the /dev/i2c2 file and expect everything to work fine or is there something im missing? Dec 25 03:27:34 depends a bit on how the i2c subsystem and driver are designed in linux Dec 25 03:28:30 if you make a syscall from an RT process then that kernel code still executes in that same process with that same scheduling/priority Dec 25 03:30:07 ah, ok. I imagine i'd run into problems if the driver calls a running kernel process though, right? Dec 25 04:33:02 sorry, I got distracted Dec 25 04:33:57 Phen: exactly, hence you may need to identify the kernel threads relevant to your RT activity and set their priorities appropriately as well Dec 25 04:34:30 note that on RT kernels nearly all irq handlers are implemented as kernel threads Dec 25 04:36:06 these by default already have real-time scheduling (SCHED_FIFO) with pretty high priority so they may not require more elevation (though you may want to demote some irqs if they are not essential to your real-time processing Dec 25 04:40:10 remember also that the more kernel calls, subsystems, and devices you use for real-time purposes, the more of the whole system will potentially affect your real-time code by e.g. grabbing a shared mutex somewhere in kernelspace Dec 25 04:44:37 (at which point you can't call it real-time anymore with a straight face) Dec 25 18:36:01 Hi, are there any news about beaglebone blue - when is it scheduled for release or is the release of that board cancelled? Dec 25 18:38:11 hmm … when is "[…] this summer […]" Dec 25 18:40:58 yeah, it seems that at some point the release was planned for last summer but postponed without a new release date. i was wondering if there's a new plan or if the product has been killed completely Dec 25 18:45:28 Anyway, if someone who knows about beaglebone blue is reading this at some point, it would be great if you could update the page https://beagleboard.org/blue with the latest information. Thanks and a happy holiday season to everyone! **** ENDING LOGGING AT Mon Dec 26 03:00:00 2016