**** BEGIN LOGGING AT Thu Feb 08 03:00:02 2018
Feb 08 03:20:34 <kenrestivo> is this the current best source for pinctrl-single,pins addreses?  http://www.embedded-things.com/wp-content/uploads/2013/08/P8.png  is there a better one?
Feb 08 03:20:49 <kenrestivo> that's quite old.
Feb 08 03:20:56 <kenrestivo> (2013)
Feb 08 03:21:09 <zmatt> well it's not like the hardware functions have changed
Feb 08 03:21:16 <zmatt> but you can also consult my spreadsheet
Feb 08 03:21:46 <zmatt> https://goo.gl/Jkcg0w   the BBB tab for a list, or P9/P8 tabs for overviews
Feb 08 03:21:58 <zmatt> I don't list the register offset, but it's 4 * pin number
Feb 08 03:22:01 <kenrestivo> thanks
Feb 08 03:23:10 <zmatt> usually people don't need that info anymore since cape-universal has been enabled by default
Feb 08 03:23:15 <zmatt> (which lets you just configure pins by name)
Feb 08 03:23:56 <kenrestivo> how can i do that in an overlay?
Feb 08 03:24:07 <kenrestivo> looks like overlays still require the addresses
Feb 08 03:24:13 <zmatt> I use a header with constants for the pins
Feb 08 03:24:28 <kenrestivo> (application: trying to get gpio-keys going)
Feb 08 03:24:35 <zmatt> e.g. https://github.com/mvduin/overlay-utils/blob/master/i2c1.dtsi#L15-L26
Feb 08 03:25:07 <kenrestivo> oh, nice! thanks!
Feb 08 03:25:12 <zmatt> this is just my custom stuff though
Feb 08 03:25:17 <kenrestivo> it's a good idea tho
Feb 08 03:25:33 <zmatt> I think the official stuff now uses constants too, but with different syntax
Feb 08 03:25:33 <kenrestivo> i didn't know #includes worked in dts
Feb 08 03:25:49 <zmatt> they do if you run it through a preprocessor
Feb 08 03:25:52 <zmatt> see Makefile
Feb 08 03:26:08 <zmatt> also I use a perl script that turns normal .dtsi syntax into the horrid mess required for overlays
Feb 08 03:26:17 <kenrestivo> __overlay__
Feb 08 03:26:22 <zmatt> that stuff
Feb 08 03:26:29 <kenrestivo> target, yep.
Feb 08 03:26:37 <kenrestivo> good stuff, thanks
Feb 08 03:27:16 <zmatt> (or, well, I just made this stuff actually... I don't actually *use* overlays myself)
Feb 08 03:27:29 <kenrestivo> where's the official stuff? i don't remember seeing any official PIN_IO_PULLUP() style macros anywhere
Feb 08 03:27:40 <kenrestivo> or at least the docs i find on beaglebone all seem to be from 2012-2014 :(
Feb 08 03:27:53 <kenrestivo> before the raspocalypse
Feb 08 03:29:26 <zmatt> browsing the dt sources I see various stuff in use
Feb 08 03:29:35 <zmatt> like  https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-pinmux-i2c2.dtsi#L32-L41
Feb 08 03:29:48 <kenrestivo> rcn, gotcha
Feb 08 03:30:02 <kenrestivo> by the way, is there any way to load overlays nowadays? capemgr seems deprecated?
Feb 08 03:30:07 <zmatt> but elsewhere  https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-bone-common.dtsi#L87-L92
Feb 08 03:30:14 <zmatt> at runtime or at boot?
Feb 08 03:30:18 <kenrestivo> runtime
Feb 08 03:30:28 <zmatt> the configfs mechanism should still work
Feb 08 03:30:36 <kenrestivo> are there docs on that?
Feb 08 03:30:37 <zmatt> my overlay-utils repository has scripts for that too, see bin dir
Feb 08 03:30:50 <kenrestivo> perfect, looking thru it now
Feb 08 03:30:55 <kenrestivo> that's one hairy perl script for dtsi
Feb 08 03:30:57 <zmatt> haven't tested them in quite a while, but should still work I think
Feb 08 03:31:21 <zmatt> I still don't understand why dtc doesn't just accept normal syntax for overlays
Feb 08 03:31:30 <zmatt> I really see no technical reason for this
Feb 08 03:31:50 <kenrestivo> history, i bet
Feb 08 03:32:10 <zmatt> overlays don't have that much history
Feb 08 03:32:23 <kenrestivo> would the dtc maintainers accept a patch to clean up the syntax?
Feb 08 03:32:41 <kenrestivo> i haven't looked at their code; not sure how easy it is to mod
Feb 08 03:32:55 <zmatt> I have no idea... have overlays even made it upstream yet?
Feb 08 03:33:17 <kenrestivo> dunno. beagle and raspberry use them heavily
Feb 08 03:33:29 <zmatt> beagle no longer really
Feb 08 03:33:47 <zmatt> overlaying is now done in u-boot
Feb 08 03:34:04 <kenrestivo> right, but i remember seeing dtbo's in u-boot
Feb 08 03:34:15 <zmatt> fair enough, for dtc it's still relevant
Feb 08 03:38:07 <kenrestivo> oh cool: /sys/kernel/config/device-tree/overlays. is that documented anywhere?
Feb 08 03:38:30 <zmatt> I think so yes
Feb 08 03:38:54 <kenrestivo> hmm, i think this is it then https://git.kernel.org/cgit/linux/kernel/git/geert/renesas-drivers.git/tree/Documentation/devicetree/configfs-overlays.txt?h=topic/overlays
Feb 08 03:39:24 <zmatt> yep
Feb 08 03:39:39 <zmatt> https://github.com/RobertCNelson/linux-stable-rcn-ee/blob/4.9.80-ti-r98/Documentation/devicetree/configfs-overlays.txt    if you want the one for the relevant kernel tree
Feb 08 03:56:42 <kenrestivo> also found this https://www.kernel.org/doc/Documentation/filesystems/configfs/configfs.txt
Feb 08 03:56:59 <zmatt> that's about configfs in general yeah
Feb 08 04:36:36 <ds2> zmatt: does your perl script do the reverse (overlay -> dts)?
Feb 08 04:39:30 <zmatt> uh, no? that would be a totally different procedure
Feb 08 04:45:34 * moto-timo scratches head and wonders why
Feb 08 04:45:49 <moto-timo> someone would ask for the reverse
Feb 08 05:49:17 <Bongobong> hm i have spidev in /dev but i am not able to interface with this device
Feb 08 05:50:20 <Bongobong> tried using an o scope to see if there was a signal but nothing, even on clock
Feb 08 05:50:36 <zmatt> did you configure the pins with config-pin ?
Feb 08 05:51:30 <Bongobong> i did not i thought that was for gpio
Feb 08 05:51:58 <Bongobong> aren't the pins for spi0 dedicated?
Feb 08 05:52:03 <zmatt> gpio is the default mode, so you actually don't need to use config-pin for that
Feb 08 05:52:13 <zmatt> no
Feb 08 05:52:24 <zmatt> almost no pins are dedicated
Feb 08 05:53:39 <Bongobong> i see
Feb 08 05:56:44 <Bongobong> are all the pins identified by p9.#?
Feb 08 05:57:10 <ds2> yes but getting rid of overlays is more interesting
Feb 08 05:57:40 <Bongobong> what do you mean
Feb 08 06:05:01 <zmatt> Bongobong: or p8.#
Feb 08 06:05:50 <Bongobong> does the p8 and p9 denote anything?
Feb 08 06:06:13 <zmatt> they're the two big expansion headers
Feb 08 06:09:23 <Bongobong> ah i see now, it makes sense thanks
Feb 08 06:16:51 <Bongobong> okay i have configured the pins p9.17 - spi_cs, p9.18 spi, p9.21 spi, p9.22 spi_sclk and still am not able to interface
Feb 08 06:34:47 <Bongobong> does it matter that the device tree overlay only has mode 0? https://github.com/nolanholden/beaglebone-c/blob/c066d9b54aecb21e58bc7d524818f8ee092dda28/overlays/BBCLIB-SPI0.dts
Feb 08 06:45:59 <zmatt> overlay? you're still trying to do something with an overlay?
Feb 08 06:50:02 <Bongobong> it's a devie tree source
Feb 08 06:50:05 <Bongobong> device
Feb 08 06:50:23 <zmatt> yes but why are you referencing it?
Feb 08 06:51:17 <zmatt> also, to double-check the current pin config you can use my show-pins script: https://github.com/mvduin/bbb-pin-utils/tree/master#show-pins
Feb 08 06:53:23 <Bongobong> okay
Feb 08 06:54:53 <Bongobong> https://i.imgur.com/r14wbJt.png
Feb 08 06:55:04 <Bongobong> i'm showing the pins configured appropriately
Feb 08 06:57:43 <Bongobong> wait shouldn't some of those be tx?
Feb 08 06:58:21 <zmatt> rx indicates receiver is enabled
Feb 08 06:58:45 <Bongobong> ah yeah
Feb 08 06:59:01 <zmatt> but yeah this looks fine
Feb 08 06:59:14 <zmatt> spidev0.0 should work with this
Feb 08 06:59:42 <Bongobong> i don't have 0.0 i have 1.0
Feb 08 06:59:56 <zmatt> oh right, stupid device numbering
Feb 08 07:00:14 <zmatt> I patched that but maybe rcn didn't merge that, or at least not in the particular kernel you have
Feb 08 07:00:37 <Bongobong> so it's likely my code rather than the device
Feb 08 07:01:27 <zmatt> may be useful to do a simple loopback test by connecting mosi -> miso and doing an inout transfer
Feb 08 07:01:51 <Bongobong> inout transfer?
Feb 08 07:02:15 <zmatt> simultaneous in and out
Feb 08 07:02:24 <zmatt> (i.e. not an in-only or out-only transfer)
Feb 08 07:03:38 <Bongobong> i'll do that and see what i get
Feb 08 07:25:05 <Bongobong> it does look like spi is working
Feb 08 07:36:05 <smitthhyy> Are serial ports enabled by default eg ttyS4?  I'm trying to send/receive between to BB's using Node-Red, just not getting data in.
Feb 08 09:34:46 <ArunKumar> Hello everyone
Feb 08 09:36:45 <sulphurik[m]> Howdy
Feb 08 09:39:14 <tbr> moo!
Feb 08 09:44:09 <ArunKumar> I just got my first BB black today and was wondering how do i setup an SPI communication to it.I plan to read two separate ADC simultaniously
Feb 08 09:44:30 <ArunKumar> is there any tutorials on this avalable?
Feb 08 11:12:04 <mattvenn_> hi
Feb 08 11:12:26 <mattvenn_> have you seen the exploring beaglebone tutorials?
Feb 08 11:12:48 <mattvenn_> http://exploringbeaglebone.com/chapter8/
Feb 08 11:14:00 <peroyvib> zmatt: I tried out your script, it gave me different indexes, I did run the rc_gpio_export(); function with "BLUE_GPI0_PIN_x" or x = 3, 4, 5 and 6 in my program. That solved the problem. But the output of your script still get me different numbers, my program did not work with those.
Feb 08 13:36:39 <pru_python> hello all, im sorry for asking this again, how can i access normal gpio via the PRU?
Feb 08 13:37:04 <pru_python> for example, the RED and GREEN leds on the blue are not connected to the pru, so how can i toggle them via the pru?
Feb 08 13:46:28 <pru_python> can i only access pr1_pru1_pru_r3x_xx type pins??
Feb 08 13:57:16 <pru_python> well the pypruss library doesn't seem to be working still,,
Feb 08 13:57:27 <pru_python> if i ignore the modprobe command
Feb 08 13:57:40 <pru_python> it just throws a "return without exception set error"
Feb 08 15:25:15 <zmatt> peroyvib: ?
Feb 08 15:25:23 <zmatt> peroyvib: not sure what you're talking about
Feb 08 15:32:07 <peroyvib> zmatt: not important, problem solved.
Feb 08 15:33:26 <zmatt> well if there's some major mistake in the blue version of my show-pins script then that is important to me... I don't think it does though
Feb 08 15:51:27 <pru_python> hello all, so i flashed debian 9.3 to my blue, and i wanted to know how to check the current device tree being used
Feb 08 15:52:27 <pru_python> according to what zmatt and jkridner said, i needed to activate the uio_pruss to be able to use pypruss so i have uncommented the following line from /boot/uEnv.txt :
Feb 08 15:53:51 <pru_python> uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo
Feb 08 15:54:07 <pru_python> do i need to add the robotics cape debt manually to uEnv.txt?
Feb 08 15:55:27 <zmatt> no since you don't have a robotics cape, you have a beaglebone blue
Feb 08 15:56:26 <zmatt> (even for capes, no manual configuration in /boot/uEnv.txt should be necessary actually)
Feb 08 15:57:04 <pru_python> so after uncommenting the boot_overlay_pru line i should be able to use pypruss like you said right?
Feb 08 15:57:11 <pru_python> with out the silly modprobe think
Feb 08 15:57:24 <pru_python> cuz when i tried it yesterday after that, it still wasn't opening the pru
Feb 08 15:57:27 <zmatt> check that uio_pruss (or something like that) is listed in lsmod after boot
Feb 08 16:03:12 <pru_python_> zmatt: hey its not enabling uio_pruss
Feb 08 16:03:20 <pru_python_> i just rebooted
Feb 08 16:04:04 <zmatt> then something is wrong
Feb 08 16:04:14 <zmatt> I'm not really awake enough yet for much tech support though
Feb 08 16:04:47 <pru_python_> alright cool
Feb 08 16:05:32 <pru_python_> can you tell me where i can find the dt blob?
Feb 08 16:05:34 <pru_python_> for the blue?
Feb 08 16:05:50 <zmatt> did you flash onto eMMC or are you running from sd card?
Feb 08 16:06:39 <pru_python_> i flashed onto eMMC, will it be in opt/source
Feb 08 16:06:42 <pru_python_> in 4.9
Feb 08 16:06:50 <pru_python_> (as im running 4/9 kernel)
Feb 08 16:06:53 <pru_python_> 4.9*
Feb 08 16:07:41 <zmatt> dtbs are in /boot/dtbs ... if you meant dt sources however, you can find them in the applicable kernel source tree (in arch/arm/boot/dts ) or in https://github.com/RobertCNelson/dtb-rebuilder
Feb 08 16:10:11 <pru_python_> you're right i needed the dts (man i need to get my jargons right), so im gonna try adding this: #include "am33xx-pruss-uio.dtsi" to it and see
Feb 08 16:10:15 <pru_python_> thanks for your time
Feb 08 16:16:22 <pru_python_> i guess the am335x-pruss-uio.dtsi is not included in 4.9 rt
Feb 08 16:34:15 <pru_python> so, i got the uio to show in asmod | grep uio
Feb 08 16:34:17 <pru_python> lsmod*
Feb 08 16:34:24 <pru_python> however pypruss not working still :(
Feb 08 16:34:39 <pru_python> "prussdrv_open open failed"
Feb 08 18:46:15 <pru_python> zmatt: I ran echo "uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo" >> /boot/uEnv.txt and echo "enable_uboot_overlays=1" >> /boot/uEnv.txt as was mentioned by jkridner (since the manual modifications i did lat time didn't work :( )
Feb 08 18:46:21 <pru_python> last*
Feb 08 18:46:37 <pru_python> also im trying to run the examples from the am335x package
Feb 08 18:46:49 <pru_python> the uio_pruss shows up in asmod, but it isn't exectuing
Feb 08 18:46:54 <pru_python> executing*
Feb 08 18:47:09 <pru_python> it throws "prussdrv_open open failed" error
Feb 08 18:54:03 <pru_python_> mesh it still only shows pru_rproc in lsmod
Feb 08 18:54:07 <pru_python_> eesh*
Feb 08 18:58:15 <pru_python_> can anyone tell me a proper way to use am335x_pru_package with the blue
Feb 08 18:58:21 <pru_python_> i want to integrate it into my project
Feb 08 19:01:32 <pru_python_> remote_proc seems way too cnvoluted
Feb 08 19:07:43 <pru_python_> how to enable the PRU on th eblue
Feb 08 19:07:57 <zmatt> wait, have you disabled remoteproc in /boot/uEnv.txt yet?
Feb 08 19:08:27 <zmatt> also, are you running from eMMC or SD ?
Feb 08 19:08:53 <zmatt> also, please undo whatever you did by messing with the dtbs, you should not have to do anything like that
Feb 08 19:09:40 <pru_python_> the line uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo is commented out
Feb 08 19:09:53 <pru_python_> and the UIO one is uncommented
Feb 08 19:10:14 <pru_python_> i have undone all the dtbs changes thanks for letting me know
Feb 08 19:10:15 <zmatt> ok, that's good, then the question becomes why this is being ignored
Feb 08 19:10:20 <zmatt> are you running from eMMC or SD ?
Feb 08 19:10:27 <pru_python_> i am running from eMMC
Feb 08 19:10:50 <zmatt> which image are you using? (cat /etc/dogtag )
Feb 08 19:11:20 <pru_python_>  2018-01-28
Feb 08 19:11:23 <pru_python_> Debian Image
Feb 08 19:13:13 <pru_python_> also if it helps, im using 4.4.148 rt kernel i think
Feb 08 19:13:18 <pru_python_> i just updated to the latest one
Feb 08 19:13:21 <pru_python_> but its 4.4
Feb 08 19:15:13 <zmatt> why did you switch?   still shouldn't matter though, remoteproc shouldn't be loading
Feb 08 19:16:24 <pru_python_> i switched because the "am33xx-pruss-uio.dtsi" was not available on 4.9
Feb 08 19:16:33 <pru_python_> so what should be done now, any ideas?
Feb 08 19:17:52 <pru_python_> Note: I have undone the dts as you mentioned so it now has #include "am33xx-pruss-rproc.dtsi"
Feb 08 19:19:21 <zmatt> it shouldn't have either of those to be honest, that's part of the overlay loaded by uboot_overlay_pru
Feb 08 19:20:07 <zmatt> maybe there are now issues because you've switched to an older kernel?  or maybe the u-boot logic for the blue is just not the same as for every other beaglebone, I don't know
Feb 08 19:21:24 <pru_python_> okay so remote proc is the way to go right now fo blue?
Feb 08 19:21:41 <pru_python_> in /usr/lib/ti/pru-software-support-package/examples/am335x how do i run the examples?
Feb 08 19:21:54 <zmatt> if I had a blue and wanted to use pru, I'd use uio-pruss
Feb 08 19:22:02 <zmatt> I don't care for remoteproc personally
Feb 08 19:22:26 <pru_python_> but currently theres no option right?
Feb 08 19:22:53 <pru_python_> what i don't understand is if in lsmod it shows that the uio_pruss is active, why is it not working
Feb 08 19:23:12 <zmatt> but you said you also saw remoteproc
Feb 08 19:23:24 <zmatt> or not?
Feb 08 19:23:33 <pru_python_> i did see
Feb 08 19:23:34 <zmatt> having both loaded would definitely be disaster
Feb 08 19:23:46 <pru_python_> should i do rmmod -f for remoteproc
Feb 08 19:23:55 <zmatt> it shouldn't load in the first place
Feb 08 19:24:06 <zmatt> well not remoteproc in general, rproc_pru or whatever it's called
Feb 08 19:24:24 <zmatt> oh what the hell, I just found this in u-boot boot script:
Feb 08 19:24:37 <zmatt> if test $board_name = BBBL; then env delete -f enable_uboot_overlays; fi;
Feb 08 19:24:56 <pru_python_> im sorry i was wrong, here is the output of lsmod | grep pru:  uio_pruss               4629  0
Feb 08 19:25:06 <pru_python_> and a bunch of other stuff
Feb 08 19:25:11 <pru_python_> with uio
Feb 08 19:25:26 <pru_python_> oh shit haha!
Feb 08 19:25:33 <pru_python_> so ill comment that out
Feb 08 19:25:36 <pru_python_> ?
Feb 08 19:25:42 <zmatt> jkridner[m]: the config you told pru_python_ is never going to work when u-boot overlays aren't even supported currently for the blue
Feb 08 19:26:03 <zmatt> pru_python_: is there any /dev/uio* device?
Feb 08 19:26:39 <pru_python_> no
Feb 08 19:27:02 <pru_python_> zmatt: no uio device in /dev
Feb 08 19:27:13 <zmatt> then you or something probably just pointlessly modprobed the uio_pruss kernel module
Feb 08 19:27:25 <zmatt> (instead of it being automatically loaded for pruss)
Feb 08 19:27:57 <zmatt> and I don't think forcibly enabling u-boot overlays would be a good idea, probably the base dtb isn't designed for it yet then
Feb 08 19:28:05 <pru_python_> would running modprobe uio_pruss have caused that? (sorry i don't understand)
Feb 08 19:28:18 <zmatt> modprobe uio_pruss   will load the kernel module
Feb 08 19:28:23 <zmatt> regardless of whether it has anything useful to do
Feb 08 19:28:52 <zmatt> if the appropriate DT declarations aren't there, the module does nothing
Feb 08 19:28:59 <zmatt> if the appropriate DT declarations are there, the module will get loaded automatically
Feb 08 19:29:06 <zmatt> that's why manually modprobing is pointless
Feb 08 19:29:12 <pru_python_> alright, so in the current state the Blue cannot use uio_pruss
Feb 08 19:29:31 <pru_python_> can't we modify the blue's dts?
Feb 08 19:29:31 <zmatt> yeah it requires a DT tweak... like you did earlier actually
Feb 08 19:29:36 <zmatt> not sure why that didn't work then
Feb 08 19:29:48 <zmatt> yeah now that I know u-boot overlays are *not* being used, that's actually the best option
Feb 08 19:30:06 <zmatt> but, I'm afk for a bit
Feb 08 19:30:42 <pru_python_> okay cool
Feb 08 19:30:58 <pru_python_> ill try including the uio.dtsi file again and see
Feb 08 19:32:09 <pru_python_> im modifying am335x-boneblue.dts
Feb 08 19:33:03 <pru_python_> I have added #include "am33xx-pruss-uio.dtsi" and commented out #include "am33xx-pruss-rproc.dtsi"
Feb 08 19:38:07 <pru_python> so i blacklisted pruss, pruss_intc and pru-rproc
Feb 08 19:38:49 <pru_python> still no uio device in /dev
Feb 08 19:40:25 <jason_94> quick question to anyone with a BBB wireless
Feb 08 19:40:47 <pru_python_> sorry i timed out cuz i shutdown my blue
Feb 08 19:40:54 <jason_94> I see it comes with the chip WiLink1835 used for wlan/ble
Feb 08 19:41:19 <jason_94> does anyone know how many simutaneous connections the WiLink1835 chip inside the BBB wireless can handle?
Feb 08 19:41:26 <jason_94> simeteanous BLE connections*
Feb 08 19:44:53 <pru_python_> jason_94: as mentioned here: http://www.ti.com/lit/ds/symlink/wl1837mod.pdf on pg 30
Feb 08 19:45:07 <pru_python_> blue can have 10 low energy connections at max
Feb 08 19:45:12 <pru_python_> ble*
Feb 08 19:49:57 <jason_94> awesome, thanks for the quick response!
Feb 08 19:50:21 <pru_python_> no worries haha
Feb 08 19:53:33 <pru_python_> zmatt: My blue was not booting up after those changes, I am refreshing it right now
Feb 08 19:54:01 <pru_python_> zmatt: uio cannot run on 4.9 kernel right?
Feb 08 19:57:02 <pru_python_> reflashing*
Feb 08 20:07:32 <pru_python> zmatt: its quite late here, so im nodding off! would you mind messaging me in case you figure out what can be done, or if nothing can? its really urgent for me. Regardless, thanks as always :)
Feb 08 21:48:54 <pru_python> zmatt: check this out: https://github.com/shubhi1407/PRU-framework
Feb 09 02:20:31 <Ray> Hi, anyone knows what is the average lifetime for beaglebone black? if i runs the device 24/7?
Feb 09 02:21:05 <zmatt> Ray: difficult to say
Feb 09 02:22:08 <zmatt> the processor itself is specified for 100K power-on hours, which is about 11.4 years if on continuously
Feb 09 02:22:14 <zmatt> my biggest worry would be the eMMC
Feb 09 02:22:45 <zmatt> you should definitely try to avoid unnecessary writes to it
Feb 09 02:23:21 <zmatt> we also reconfigure the eMMC into SLC mode to improve reliability and longevity (as the cost of 50% of storage space)
Feb 09 02:23:29 <zmatt> *at
Feb 09 02:25:09 <zmatt> recently we had a little mishap where a software bug caused a fairly large file to be rewritten way too often, resulting in 16 GB of data being written per hour
Feb 09 02:25:19 <zmatt> that beaglebone was dead in weeks
Feb 09 02:26:05 <zmatt> (that was with eMMC still in MLC mode)
Feb 09 02:28:09 <Ray> which means that by using the eMMC often, it decreases the lifetime of the Beaglebone Black?
Feb 09 02:28:40 <zmatt> flash memory has a limited amount of lifetime writes
Feb 09 02:28:56 <zmatt> so the more data you write, the sooner the eMMC will die
Feb 09 02:29:16 <ds2> what's the ratings on the PMIC?
Feb 09 02:29:37 <ds2> eMMC can be avoided/worked around... PMIC less so
Feb 09 02:30:59 <zmatt> if the device is embedded, loss of your boot storage device is typically not something you can "work around"
Feb 09 02:32:31 <ds2> not if you have a standby uSD card sitting there...device diversity
Feb 09 02:33:29 <zmatt> that sounds like a very complicated setup for little benefit... most uSD cards will die in a short amount of time compared to eMMC (especially if reconfigured to SLC, which you can't do with SD cards afaik)
Feb 09 02:35:47 <ds2> w/o knowing more about the actual application, that seems like a very general statement
Feb 09 02:35:54 <zmatt> at work, use of the card slot was also dismissed because the card isn't held locked in place (it's just held in by some friction)
Feb 09 02:36:05 <ds2> uSD can be a service item
Feb 09 02:36:33 <zmatt> if that is an option then yes
Feb 09 02:36:56 <zmatt> so far Ray however doesn't seem inclined to comment on his particular situation, so I
Feb 09 02:37:01 <ds2> that holder can be iffy... another option is to have that card there and and have the card boot into a rescue image
Feb 09 02:37:03 <zmatt> 'll just stop speculating
Feb 09 02:37:07 <ds2> *nod*
Feb 09 02:37:57 <ds2> i am curious as to the rated life of the PMIC vs the main SoC... the PMIC potentially has a harder life
Feb 09 02:38:59 <zmatt> I haven't seen any lifetime rating in it... I thought the pmic was a pretty robust thing?
Feb 09 02:39:43 <ds2> yes but it is a bunch of regulators taking input from things that may have spikes and other nasties (i.e. unplugging a power cube)
Feb 09 02:43:43 <zmatt> well, let me know when you get an answer about this from TI :)
Feb 09 02:46:04 <ds2> heh
Feb 09 02:46:39 <zmatt> what?  asking for device lifetime seems like a pretty legitimate question
Feb 09 02:47:06 <zmatt> I feel like you ought to get some sort of answer to that if you ask it on e2e
Feb 09 02:54:13 <Bongobong> my spi signal has noise in it i think how do i get it out
Feb 09 02:54:16 <Bongobong> https://i.imgur.com/ROhziyo.jpg
Feb 09 02:55:06 <Bongobong> referring to the voltage not going to the same level as the others
Feb 09 02:55:31 <zmatt> those weird slopes are due to the line being tristated outside of transfers
Feb 09 02:56:06 <zmatt> so if the last bit was 0 it'll slowly get pulled up (by the internal pull-up that's enabled by default)
Feb 09 02:56:26 <zmatt> this does not happen during a transfer so it should not matter
Feb 09 02:56:49 <Bongobong> rgr that
Feb 09 02:56:49 <zmatt> (i.e. clock is idle and chip select deasserted when this happens)
Feb 09 02:58:47 <zmatt> I'm also seeing some overshoot here and there, you should be able to suppress that using a small series resistor
Feb 09 02:58:58 <zmatt> (placed near the driving side)
**** ENDING LOGGING AT Fri Feb 09 03:00:01 2018