**** BEGIN LOGGING AT Thu Feb 14 02:59:57 2019
Feb 14 03:00:13 <mawk> dreamhiker: you do win+R then type DISKMGMT.MSC
Feb 14 03:00:18 <mawk> you can change the driver letter here
Feb 14 03:00:35 <mawk> right click on the volume, delete the old drive letter, add a new one
Feb 14 03:03:28 <Andre> hey _set
Feb 14 03:03:34 <Andre> sorry set_
Feb 14 03:04:58 <Andre> testing if the board is strong enough for our kiosk
Feb 14 03:05:23 <set_> Oh.
Feb 14 03:05:30 <set_> That is nice.
Feb 14 03:05:41 <Andre> I really hope it will work out!
Feb 14 03:05:45 <set_> When you typed strong, what do you mean?
Feb 14 03:05:48 <Andre> You guys did amazing work
Feb 14 03:05:52 <set_> Not me.
Feb 14 03:05:58 <Andre> we got the nodejs app
Feb 14 03:06:14 <set_> I did not build that or any of their boards.
Feb 14 03:06:25 <Andre> ;)
Feb 14 03:06:37 <set_> I just like Q & A and chatting about the BBB.
Feb 14 03:06:40 <Andre> ;)
Feb 14 03:06:46 <Andre> thanks ;)
Feb 14 03:06:58 <Andre> need to build custom kernel now
Feb 14 03:07:00 <Andre> heheheheh
Feb 14 03:07:08 <set_> Okay. Andre: Okay. Have fun.
Feb 14 03:07:49 <Andre> do you think sata driver is a kernel module or is it compiled into kernel?
Feb 14 03:08:14 <Andre> this is what I am trying to figure out now
Feb 14 03:08:19 <set_> Oh.
Feb 14 03:08:33 <set_> In google, type "linux sata driver."
Feb 14 03:08:34 <Andre> (I am quite tired at the moment honestly)
Feb 14 03:08:39 <set_> Oh.
Feb 14 03:09:01 <Andre> OK
Feb 14 03:09:13 <Andre> maybe you know answer to this question
Feb 14 03:09:22 <set_> yea. Just try that. It may surprise you.
Feb 14 03:09:29 <Andre> is there a build for bbbx15
Feb 14 03:09:42 <set_> Oh. No. I have no idea about the sata stuff.
Feb 14 03:09:43 <set_> Yes.
Feb 14 03:09:47 <Andre> the small one without graphic interface?
Feb 14 03:09:57 <Andre> its not just debian
Feb 14 03:10:16 <set_> bbb x15 has its own image.
Feb 14 03:10:24 <Andre> I need to get to the point of make menu for the current kernel and I will know ;)
Feb 14 03:11:38 <set_> https://www.digikey.com/eewiki/display/linuxonarm/BeagleBoard-X15
Feb 14 03:12:03 <set_> That should walk you through the steps on how to manage your own image.
Feb 14 03:13:09 <set_> Andre: Did you see that page yet?
Feb 14 03:13:28 <Andre> Oh yes!
Feb 14 03:13:40 <set_> Is that okay for what you need to do?
Feb 14 03:13:51 <Andre> Thank you!
Feb 14 03:14:25 <set_> Yep. And this eewiki has a forum, too. If you search for it, you will find it.
Feb 14 03:14:59 <Andre> Thanks!
Feb 14 03:15:03 <set_> That place has a bunch of knowledgeable staff that support people at times.
Feb 14 03:15:14 <Andre> I was looking for minimal version for bbbx15
Feb 14 03:15:21 <Andre> and you just helped me find it!
Feb 14 03:15:34 <set_> Oh...yea. You can set that up easily I bet.
Feb 14 03:16:03 <set_> I once talked to someone on that page for over 150 replies. I kept making mistake after mistake. Oops.
Feb 14 03:16:04 <Andre> I will have room to compile it on the board!
Feb 14 03:16:18 <set_> Yep...
Feb 14 03:17:36 <set_> Andre: Good luck and Godspeed. I will look around for other info. when we chat again next. Have fun!
Feb 14 03:17:53 <set_> Kiosk? Like in the mall?
Feb 14 03:18:11 <Andre> sort of ;)
Feb 14 03:18:16 <set_> or are you holding a booth at some science fair?
Feb 14 03:18:24 <Andre> I wish!
Feb 14 03:18:27 <Andre> honestly ;)
Feb 14 03:18:33 <set_> Okay.
Feb 14 03:18:38 <Andre> Thanks for help again!
Feb 14 03:18:41 <Andre> Appreciate it!
Feb 14 03:18:46 <set_> Yep.
Feb 14 03:18:49 <set_> Later for now.
Feb 14 03:18:56 <Andre> Have a good night!
Feb 14 04:33:00 <Devan> What is the voltage  limit for the x15 before it gets damaged
Feb 14 14:37:56 <kremlin> m
Feb 14 15:29:18 <Guest71492> I have no premissions to pru, what can i do?
Feb 14 15:29:31 <Guest71492> beaglebone black
Feb 14 15:30:47 <zmatt> Guest71492: what do you mean exactly?
Feb 14 15:31:11 <zmatt> and are you using uio-pruss or remoteproc-pru?
Feb 14 15:31:37 <Guest71492> yes
Feb 14 15:32:04 <zmatt> ehm, "yes" is not a useful answer to either of those questions
Feb 14 15:32:05 <Guest71492> set status
Feb 14 15:32:35 <Guest71492> => /sys/class/remoteproc/remoteproc1 set the status or start and stop
Feb 14 15:32:53 <Guest71492> i have always premission denied
Feb 14 15:33:17 <zmatt> oh, I don't know how the permissions are setup in case of remoteproc-pru, I only use uio-pruss
Feb 14 15:33:29 <zmatt> my guess would be no permissions have been set up at all, hence root privileges are required
Feb 14 15:33:43 <zmatt> you can use sudo
Feb 14 15:33:47 <Guest71492> i did it as root
Feb 14 15:34:22 <zmatt> then either you did something wrong, or you're confused about how the remoteproc interface works
Feb 14 15:35:07 <zmatt> can you give an example of a command you've tried that failed?
Feb 14 15:35:59 <Guest71492> echo 'start' > /sys/class/remoteproc/remoteproc1/state
Feb 14 15:37:00 <zmatt> what does ls -l /sys/class/remoteproc/remoteproc1/state  show?
Feb 14 15:37:16 <Guest71492> offline
Feb 14 15:37:21 <zmatt> note that putting "sudo" in front of that would not have the result you desire
Feb 14 15:37:26 <zmatt> no, I asked ls -l, not cat
Feb 14 15:38:16 <zmatt> sudo echo start >file   would redirect the output of "sudo echo start" to the file, but the file would still be opened with normal privileges, not with root privileges
Feb 14 15:38:52 <zmatt> easiest workaround for that is to just open a root shell using "sudo -i" and type the command there
Feb 14 15:40:28 <zmatt> a better solution would be to change its permissions using:  sudo chown debian /sys/class/remoteproc/remoteproc1/state
Feb 14 15:40:38 <zmatt> then you'll be able to write to it as normal user
Feb 14 15:41:18 <Guest71492> ls: cannot access 'status': No such file or directory
Feb 14 15:41:38 <zmatt> it's called state, not status
Feb 14 15:41:54 <Guest71492> sorry
Feb 14 15:41:58 <Guest71492> -rw-r--r-- 1 root root 4096 Feb 14 15:41 state
Feb 14 15:42:50 <zmatt> anyway, it sounds like your main confusion is because you tried to do "sudo echo start >/sys/class/remoteproc/remoteproc1/state", which doesn't work for the reason I just explained
Feb 14 15:44:06 <Guest71492> after changing the premissions i get -bash: echo: write error: No such file or directory
Feb 14 15:44:15 <zmatt> my suggestion would be to use "sudo chown debian /sys/class/remoteproc/remoteproc1/state" to allow the debian user to access it (you only need to do this once after boot) and then simply "echo start >/sys/class/remoteproc/remoteproc1/state" should work
Feb 14 15:44:31 <zmatt> that's probably just an error from the remoteproc framework
Feb 14 15:44:34 <zmatt> check kernel log
Feb 14 15:44:40 <zmatt> I don't know much about remoteproc, I don't use it
Feb 14 15:46:22 <Guest71492> all what i did, is enable the pruss in the device tree "disabled" to "okay"
Feb 14 15:46:35 <zmatt> ehm, what do you mean?
Feb 14 15:46:41 <zmatt> remoteproc-pru is enabled by default
Feb 14 15:47:21 <zmatt> which debian image are you using?
Feb 14 15:47:32 <Guest71492> realy i get only one remoteproc0 with the default image
Feb 14 15:47:49 <zmatt> then something is wrong.  are you booting from eMMC or SD card?
Feb 14 15:48:00 <Guest71492> sd card
Feb 14 15:48:18 <zmatt> assuming you don't care about the contents of eMMC, wipe it using "sudo blkdiscard /dev/mmcblk1"
Feb 14 15:48:30 <zmatt> an old bootloader on eMMC can cause functionality to break when booting from sd card
Feb 14 15:49:41 <zmatt> in /boot/uEnv.txt there's a setting "uboot_overlay_pru" that's used to select whether to enable remoteproc-pru or uio-pruss.  by default it is set to remoteproc-pru
Feb 14 15:49:49 <zmatt> an old bootloader may however not understand that setting
Feb 14 15:50:00 <zmatt> wiping eMMC forces the system to use the bootloader on SD card instead
Feb 14 15:51:13 <Guest71492> okay
Feb 14 15:51:31 <zmatt> whatever you did to somehow enable pruss anyway, you should probably undo it
Feb 14 15:54:10 <zmatt> if you only care about getting pru to work, and don't need remoteproc-pru specifically, you may also be interested in my python library for working with pru (loading programs, inspecting/modifying pru state, mapping shared memory, receiving interrupts, etc): https://github.com/mvduin/py-uio
Feb 14 16:01:15 <Guest71492> unfortunately i need this remoteproc-pru, because i try to control several bus systems
Feb 14 17:37:52 <gitty-boi> JOIN
Feb 14 17:38:12 <gitty-boi> is there a gitter channel for beagleboard?
Feb 15 00:43:22 <mawk> zmatt: the baud rate you recommended with the bbb is 460800 right ?
Feb 15 00:43:38 <mawk> I see even higher baudrates in <termios.h> but I guess my cables are too lame for it
Feb 15 01:33:45 <rowsail> Is the BBB ready for 'prime time' - seems there are some design issues even with Rev C which might preclude it being used in an application where power cycling or hitting reset is not an option?
Feb 15 01:42:16 <rowsail[m]> Is the BBB ready for 'prime time' - seems there are some design issues even with Rev C which might preclude it being used in an application where power cycling or hitting reset is not an option?
Feb 15 01:49:41 <veremitz> its been around for a good number of years now .. the cpu is an industrial control processor .. what are your specific requirements?
Feb 15 01:57:40 <rowsail[m]> It is a controller for a remote piece of equipment.  There is a known issue on Rev C where the etherenet PHY is not reset properly after power cycle.
Feb 15 02:00:52 <rowsail[m]> Unit was chosen because it has been around for some years yet even at Rev C there is this issue.  See here:  https://github.com/beagleboard/beaglebone-black/issues/4
Feb 15 02:02:25 <rowsail[m]> But what has me really worried are the problems this company has found (scroll to the last but one reply from here: https://wp.josh.com/2018/06/04/a-software-only-solution-to-the-vexing-beagle-bone-black-phy-issue/
Feb 15 02:03:58 <rowsail[m]> I have a new design (PCBs arrived today) that needs to run 24hrs per day without human intervention. If others have succesfully done this then I'll feel a bit happier - the problems referenced might just be outliers.  But if most applications have not been commercial I'm going to have to rethink teh whole project (in 2 weeks!)
Feb 15 02:13:23 <veremitz> yeah there's nothing preventing commercial use of the BBB .. but it's probably a case of YMMV :/
Feb 15 02:13:40 <veremitz> I don't think there are any guarantees expressed or implied
Feb 15 02:14:00 <veremitz> jkridner[m]: ^ any thoughts?
Feb 15 02:15:36 <rowsail[m]> Seems that is the case i.e. not quite ready for Prime Time!
Feb 15 02:15:44 <veremitz> rcn-ee[m]: ^ I see you commented also :D
Feb 15 02:16:19 <veremitz> sounds liek there's a patch in the wild ..
Feb 15 02:16:22 <rowsail[m]> The fix to the Ethernet is an easy one, but needs a board change to route a GPIO line to the PHY.   The kernel also supports this reset.
Feb 15 02:16:31 <veremitz> right, so I'm reading :)
Feb 15 02:16:56 <veremitz> my BBB (fwiw) has an uptime of ..
Feb 15 02:17:22 <veremitz> [ 1:36am] root@beagleblack ~ # uptime
Feb 15 02:17:22 <veremitz>  02:17:09 up 186 days, 19:06,  2 users,  load average: 0.36, 0.14, 0.11
Feb 15 02:17:22 <veremitz> [ 2:17am] root@beagleblack ~ # uname -a
Feb 15 02:17:23 <veremitz> Linux beagleblack 3.13.6-bone7.2 #1 SMP Fri Mar 21 03:59:54 GMT 2014 armv7l GNU/Linux
Feb 15 02:17:32 <veremitz> and thats the 2G version.
Feb 15 02:17:37 <rowsail[m]> But the issues reported by that German company are particularly worrying.
Feb 15 02:17:39 <veremitz> its my local DHCP server.
Feb 15 02:17:46 <rowsail[m]> Sure, once it is running - all seems OK.
Feb 15 02:17:56 <rowsail[m]> But power cycling is a different story.
Feb 15 02:17:58 <veremitz> never experienced a fault myself.
Feb 15 02:18:21 <veremitz> but for anythign remote, without telemetry .. sure, you'd be wise to be careful
Feb 15 02:18:37 <rowsail[m]> Seems that the PHY does not always get reset properly (the reset circuit on the BB is a crude RC circuit).
Feb 15 02:19:54 <veremitz> that's unfortunate .. a reset chip like the .. err .. DSwhatever is easy/cheap enough
Feb 15 02:20:31 <veremitz> I can't remember right now which one it was .. either  a 3 or 5 SOT23 most likely
Feb 15 02:21:10 <rowsail[m]> Yes - that is my thinking.  I think the software fix which power cycles the BB if the PHY is not detected after boot will be OK for this application - but imagine an application where someone is expecting to interact soon after power on.  They might wait 20s max - but if it then needs to reboot and it's another 20s just because the PHY didn't come up then there's going to be a service call!
Feb 15 02:21:37 <veremitz> aye...
Feb 15 02:21:47 <rowsail[m]> re the rest chip - yes, very cheap.  I'm hoping that adding one to teh 'cape' might help.
Feb 15 02:21:49 <rowsail[m]> reset
Feb 15 02:22:28 <rowsail[m]> Thanks for the chat.
Feb 15 02:22:47 <veremitz> np, good luck with the project.
Feb 15 02:23:07 <veremitz> as long as the reset chip pulls the line hard enough, I'da thought it'd be Better at least :D
Feb 15 02:24:21 <rowsail[m]> Cannot hurt ;-)
Feb 15 02:25:35 <rowsail[m]> BTW - RT9818C-29GV.  Keeps reset low until supply reaches 2.9V and then holds low for a few hundred ms.
Feb 15 02:26:19 <veremitz> ds1810 could have been .. but that's looking expensive lol
Feb 15 02:26:24 <rowsail[m]> $0.10 from Digikey
Feb 15 02:29:18 <veremitz> lgtm
**** ENDING LOGGING AT Fri Feb 15 02:59:56 2019