**** BEGIN LOGGING AT Mon Jul 31 03:00:03 2017 Jul 31 11:46:19 zmatt : when i write kernel module, can i mux the pins by writing to the pinmux register? Jul 31 11:46:26 zmatt: or the kernel blocks it? Jul 31 11:54:49 why would you want to do that? Jul 31 11:55:03 i want to write a pulse tool Jul 31 11:55:10 something that will generate a pulse with each pin i select Jul 31 11:55:11 devicetree is for setting up mux Jul 31 11:55:34 i don't want pwm (because its only for specific pins) nor pru (i'm having sitara without pru) Jul 31 11:55:40 and i need a ms resolution Jul 31 11:55:57 so what does all this have to do with pinmux? Jul 31 11:56:00 eventually i need a command line like : GeneratePulse Jul 31 11:56:15 because i need to flag a GPIO , and i need to mux it out to the pin i select Jul 31 11:56:18 that doesn't necessitate runtime mux though Jul 31 11:56:35 you need to do this on bits normally used for functions other than gpio? Jul 31 11:56:38 *pins Jul 31 11:56:48 yes. Jul 31 11:56:55 i need to be flexible to pick any pin i choose. Jul 31 11:57:06 for test purposes I presume Jul 31 11:57:23 you can change pinmux directly of course Jul 31 11:58:07 can i change it at application space? or i need to write kernel module? Jul 31 11:59:06 the pinmux registers can only be written using kernel-mode writes, but you can map the registers via /dev/mem and trick the kernel into writing to them. i do this in https://github.com/dutchanddutch/jbang/ Jul 31 11:59:41 specifically here https://github.com/dutchanddutch/jbang/blob/master/src/hw-subarctic.cc#L17 Jul 31 12:00:31 (the nice C++ wrapper ultimately becomes a call to process_vm_readv. that's not the only syscall you can abuse for this purpose though) Jul 31 12:04:34 zmatt: can i configure a timer interrupt at linux application ? or i also must use the linux kernel module? Jul 31 12:04:53 zmatt: or is there any way to have a 0.5 ms resolution at user space? Jul 31 12:06:32 0.5 ms should be no problem Jul 31 12:08:40 you can minimize jitter by giving the userspace process real-time scheduling (man sched_setscheduler) Jul 31 12:43:16 zmatt: and i should use the system timer for it? Jul 31 13:56:33 "the system timer" ? Jul 31 14:02:28 probably the nicest way to make an interval timer in userspace is using timerfd (man timerfd_create). use CLOCK_MONOTONIC as clock id Jul 31 14:39:46 zmatt : when working with user-space (with high priority) can i be 100% sure that it won't be delayed over 1ms ? (even when the system is under stress)? Jul 31 14:42:22 no cyberguy Jul 31 14:42:33 although 1ms is very unlikely Jul 31 14:44:05 all real time operations should be done on the PRU and just picked up from the linux i would suggest Jul 31 14:48:44 crap! , so if i don't have a PRU. the only alternative is kernel module with interrupt? Jul 31 14:48:58 (my device wi AM335x without PRU...) Jul 31 14:50:29 kernel module with interrupt gives you not that much without having a preempt-rt enabled kernel Jul 31 14:52:35 why is that? the interrupt is not immediately invoked?!?!? if i configure the timer for 500us , it wont invoked immediately ? Jul 31 14:53:31 because os, switching latency, etc. Jul 31 14:54:18 so its the same as task with high priority? Jul 31 14:54:28 althought it is a kernel module? Jul 31 14:55:03 the point is, can you accept a missed deadline now and then. then you'r basically fine with a standard kernel. if your deadlines are critical, then you should have a pru, or at least preempt-rt or xenomai Jul 31 14:55:19 cyberguy: just because its in the kernel doesn't mean that there's no context switch. Jul 31 14:58:52 Is there any estimation for such cause? my deadline is 1.5ms Jul 31 15:01:40 there is only an "in the most cases you'll be fine" Jul 31 15:04:41 what about the beaglebone black rt kernel ? is it preempt-rt ?! Jul 31 15:09:29 will preempt-rt will promise me a dead line on timing? Jul 31 15:09:51 nobody will give you a guarantee Jul 31 15:10:41 preempt-rt will probably keep deadlines in that range. but nobody will sign you a guarantee and ake the blame if it doesn't Jul 31 15:48:38 you realize that 1.5ms is a LOT of time right? Jul 31 15:49:20 more likely latencies, even to userspace, would be less than 0.1 ms Jul 31 18:21:45 cyberguy: what are you trying to do anyway? why do you need guaranteed precisely timed gpio pulses on random pins you normally use for other purposes? this is starting to sound rather bizarre Jul 31 21:03:20 Hello! Jul 31 21:03:24 Hi! Jul 31 21:04:08 I hope you can help me, I am trying to set the MAC adress on my Beagleboard Jul 31 21:04:39 Do you know if this is possible? Jul 31 21:04:53 Beagleboard xm Jul 31 21:07:13 * zmatt doesn't really know much about the xM, but checks anyway Jul 31 21:08:11 thx! Jul 31 21:10:00 the lan9514 chip doesn't have an eeprom attached, so software is responsible for configuring its MAC address somewhere after power-on... Jul 31 21:13:23 oh, not good for me.... Jul 31 21:14:04 why do you want to change the mac address? Jul 31 21:14:10 that's not a very typical thing to do Jul 31 21:14:47 I would like to have a fixed mac so I can set up an fixed IP on my router Jul 31 21:14:59 oh it has a random mac right now? hmm Jul 31 21:15:11 yes, random Jul 31 21:15:22 every time it is different Jul 31 21:15:34 u-boot seems to generate one based on the die id, which should be the same across boots, but I guess that's not passed down to the kernel then Jul 31 21:16:31 Do you think I can set it using a script on boot up? Jul 31 21:16:34 there are probably multiple ways to fix this... but it might require some digging Jul 31 21:18:03 systemd-networkd (which is the network manager I use myself) actually has config options for this Jul 31 21:19:44 I suspect most network managers actually will have an option for it somewhere Jul 31 21:21:08 How can I discover what kind of network manager is running on bb xm? Jul 31 21:21:37 what distro are you using? Jul 31 21:22:23 Debian 8 Jul 31 21:25:35 on my BBG, I keep getting a "The root filesystem on /dev/mmcblk1p1 requires a manual fsck" then it boots into initramfs saying "rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY." Is there a way I can automate this process so I don't have to hook it up to a FTDI serial to fix a corrupt fs? Jul 31 21:26:32 MRCG: check the output of systemctl status Jul 31 21:26:50 MRCG: probably lists something like connman.service or networking.service Jul 31 21:27:32 clockman: this means you're suffering serious filesystem corruption... you should prevent it rather than sweeping it under the carpet Jul 31 21:27:53 otherwise you'll eventually have a non-working system anyway Jul 31 21:28:15 the problem is that it loses power. and there are some files that are reporting incorrect file sizes. Jul 31 21:28:53 I know this because running fsck from initramfs fixes the problem and says that Jul 31 21:29:24 I've cut power to a beaglebone lots and lots of times and never got something like that Jul 31 21:29:43 but eMMC is pretty intolerant to power loss during writes Jul 31 21:30:34 You are right, I found connman.service Jul 31 21:31:13 though we've actually reconfigured the eMMC of our production beaglebones into SLC mode with "reliable writes" enabled exactly to mitigate the risk of filesystem corruption due to power loss Jul 31 21:31:32 MRCG: then you're using connman :) Jul 31 21:31:38 MRCG: I know absolutely nothing about connman Jul 31 21:32:38 zmatt, thank you for your help, you are very kind, tomorrow I will find info about this service. Jul 31 21:32:54 Now it's time to go to sleep, best regards from Italy! Jul 31 21:32:58 if it doesn't have an option to configure MAC address, or it's difficult to locate, I also like the suggestion I've seen while googling to use an udev rule that just calls "ip link" to set the mac address Jul 31 21:33:39 ok, thanks! Jul 31 21:35:36 clockman: note that if filesystem corruption is happening, almost certainly there will also be corruption of data stored in the filesystem Jul 31 21:36:00 so if you care about the data being written to eMMC, I'd suggest finding a solution Jul 31 21:36:15 if you don't care about the data being written to eMMC, then don't write it to eMMC... Jul 31 21:36:37 okay, i'll try to track down *why* it's f-ing up, and on multiple BBG's Jul 31 21:36:58 (reducing eMMC writes will also decrease the risk of filesystem corruption, and increase the longevity of the eMMC) Jul 31 21:37:56 and as I mentioned it is possible to configure certain settings in eMMC related to reliability Jul 31 21:38:18 but these will trade off against storage space and/or performance, and they're one-time-programmable (irreversible) Jul 31 21:38:38 maybe i'll hold off on that - I may ask you about that at a later date. Jul 31 21:39:43 an interesting thing I did notice is that, although we reconfigured to SLC for reliability reasons, it also increase write speed by a factor of 3 -- despite that we also enabled "reliable writes" (which presumably hurts performance) Jul 31 21:41:39 basically, in its default setting, eMMC requires clean shutdown, and does not guarantee any of your data is still there if you cut power during write :) (although in practice it's not *that* dire of course) Jul 31 21:42:20 another alternative we've considered is a small li-ion battery to give the system time to shut down after power loss Jul 31 21:42:54 which eMMC does the BBG use anyway? Jul 31 21:43:02 in practice, it depends STRONGLY on brand and model of the eMMC used Jul 31 21:43:07 yeah Jul 31 21:43:37 Kingston/Micron, IIRC Jul 31 21:43:52 there are industrial eMMC that are more tolerant to power loss Jul 31 21:44:08 the fancy eMMC in the Pyra actually has the "reliable writes" setting always enabled, i.e. the manufacturer doesn't gamble with your data to get better benchmark numbers :) Jul 31 21:44:49 (not that they would need it, their numbers are pretty awesome) Jul 31 21:49:39 is the pyra shipping ? Jul 31 21:51:14 not yet Jul 31 21:52:25 there are a bunch of prototypes now in the hands of devs, but there are still some things that need to be ironed out Jul 31 21:59:02 anyone here? Jul 31 21:59:28 not really, we're just here for decorative purposes Jul 31 21:59:47 well, u look cool :P Jul 31 22:03:09 zmatt: are they sticking with the O5? Jul 31 22:03:21 O5 ? Jul 31 22:03:26 Omap5 Jul 31 22:04:16 that choice was made a long long time ago Jul 31 22:04:56 to be fair, there wasn't that much choice Jul 31 22:05:13 although it still seems like a .... courageous choice :P Jul 31 22:05:22 *seemed Jul 31 22:07:22 it isn't that painful to move to a derivative Jul 31 22:07:56 what derivative? the am57xx ? in a handheld ? Jul 31 22:12:07 bbl, gotto catch bus Jul 31 23:13:47 Help. I just recieved my BBB and was following the Arrow startup youtube video. All was fine but after I did an UPDATE I also did an UPGRADE command. Now I can not access the Cloudo IDE. Any suggestions? Jul 31 23:14:30 I meant Cloud9 IDE. Jul 31 23:15:58 I am connected via usb. Jul 31 23:19:25 uhh, hard to say... what got updated? Jul 31 23:20:17 if the firmware flashed on it was quite old to begin with it may be worth reflashing it with the latest Jul 31 23:20:48 Lots of files. I stepped away for a moment and came back and it went offline. Jul 31 23:21:46 It was a brand new board and I was probably not supposed to use the UPGRADE command. The UPDATE went fine just before this. Jul 31 23:22:07 update just checks for the latest packages, it doesn't install anything Jul 31 23:22:28 if it tried to install lots of stuff, my hypothesis would be it ran out of free space during the installation Jul 31 23:22:38 apt handles that very very poorly :-/ Jul 31 23:23:39 probably the system was pretty old... you never know how much time has passed between production and ending up on your doorstep Jul 31 23:23:56 Any suggestions on how I get back to the starting line. Jul 31 23:24:35 yeah, what I said above... reflash it Jul 31 23:25:13 http://elinux.org/Beagleboard:BeagleBoneBlack_Debian Jul 31 23:26:03 I'd suggest the latest Jessie "iot" flasher Jul 31 23:26:07 This is a beagleboard blue. Does that make a difference on how I flash it? I did not have to use an SD card up to this point and any installation. Jul 31 23:26:38 you need an sd card to reflash it, you don't need the sd card after that Jul 31 23:27:17 btw "BBB" is generally understood to mean "beaglebone black" .. for the blue say bbblue or bbbl or something :) Jul 31 23:27:57 download the file listed under http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flasher:_.28iot.29_.28All_BeagleBone_Variants.29 Jul 31 23:28:03 "Flasher: (iot) (All BeagleBone Variants)" Jul 31 23:29:49 then use e.g. the suggested etcher.io program to write it to sd card, boot the bbblue from the card... the leds will do a back-and-forth pattern for a while and finally all leds go on, and I think the device powers off (it didn't use to do that but it seems to nowadays) Jul 31 23:30:15 Sorry about nomenclature. I will reflash the board. Thanks very much for the help! Jul 31 23:31:43 and keeping the system uptodate using apt update && apt upgrade is generally recommended, despite your not-so-great first experience with that command :) Jul 31 23:32:21 but problems can arise when doing so after it hasn't been updated in ages Jul 31 23:34:19 Thanks zmatt! I will try for the better experience this time. Aug 01 02:15:21 anyone with beaglebone blue experience have a good reference page for how to control the motors/encoders Aug 01 02:25:59 found it Aug 01 02:29:53 https://github.com/StrawsonDesign/Robotics_Cape_Installer Aug 01 02:45:57 wow but are docs on which pin in which socket is what scarce for BB Blue Aug 01 02:55:19 https://github.com/beagleboard/beaglebone-blue/blob/master/BeagleBone_Blue_sch.pdf **** ENDING LOGGING AT Tue Aug 01 03:00:00 2017