**** BEGIN LOGGING AT Wed Dec 06 03:00:00 2017
Dec 06 05:12:54 <charlestx> Try to update eMMC of my BBG
Dec 06 05:14:06 <charlestx> BUT how to get into login as: set up the standalone microSD image to automatically flash the eMMC on powerup. Login as debian (password = temppwd) and edit /boot/uEnv.txt with nano (sudo nano /boot/uEnv.txt) or your preferred editor.
Dec 06 05:15:35 <charlestx> as in https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC
Dec 06 05:16:15 <zmatt> uhh, with the default login/password, debian/temppwd
Dec 06 05:16:34 <zmatt> same as you would log into your BBG after reflashing it
Dec 06 05:17:53 <charlestx> the http://192.168.7.2/bone101/  login button on the upperleft did not response
Dec 06 05:20:16 <zmatt> I don't know anything about the web interface, I never use it.  although it should work obviously. (until you change the card to be a flasher, it behaves almost exactly like a flashed system would)
Dec 06 05:20:37 <charlestx> I means how to "you need to launch to the board, and modify a file" to get to /boot/uEnv.txt
Dec 06 05:21:13 <zmatt> ssh
Dec 06 05:22:02 <charlestx> since BBG do not have HDMI to monitor so just have to connect to PC
Dec 06 05:23:20 <zmatt> I never work on a bbb using monitor+keyboard, I just use ssh
Dec 06 07:30:02 <kenrestivo> what's the current means of enabling a .dtbo? i've tried a couple approaches to adding it to uEnv.txt, none seem to work
Dec 06 07:30:20 <kenrestivo> https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#U-Boot_Overlays seems current, most of the other docs seem to talk about capemgr which i gather is depreciated
Dec 06 07:45:13 <zmatt> depends on which image version you're running... can you pastebin the contents of your uEnv.txt ?
Dec 06 07:46:10 <zmatt> they're not used as heavily anymore as they used to be, since cape-universal became the default (allowing pin function to be configured at runtime)
Dec 06 07:53:03 <kenrestivo> ah, maybe that's the way to do it. i was using the gpio_keys kernel module
Dec 06 07:53:22 <kenrestivo> some of this stuff is just *old*.
Dec 06 07:54:28 <kenrestivo> thanks, i'll look into approaches that use cape-universal instead
Dec 06 07:59:02 <Ritesh> I want to play some audio in BBGW and followed https://github.com/beagleboard/bb.org-overlays/issues/39 link
Dec 06 07:59:24 <Ritesh> but got stuck in the same
Dec 06 07:59:36 <Ritesh> can anyone help me in the same
Dec 06 08:01:02 <Ritesh> https://github.com/beagleboard/bb.org-overlays/issues/39 mentioned link is not working for m
Dec 06 08:02:05 <Ritesh> Need to  get audio to output on the I2S port with a Beaglebone Green Wireless
Dec 06 08:02:31 <Ritesh> tried to change in dtbo file
Dec 06 08:03:13 <Ritesh> as I am very new to linux so not hving any idea of dts file
Dec 06 08:03:25 <Ritesh> can any one tried the same
Dec 06 08:04:35 <Ritesh> even getting below error while compiling the dts file
Dec 06 08:04:37 <Ritesh> sudo dtc -O dtb -o am335x-bonegreen-wireless.dtbo -b 0 -@ am335x-bonegreen-wireless.dts [sudo] password for ubuntu:  Error: am335x-bonegreen-wireless.dts:10.1-9 syntax error FATAL ERROR: Unable to parse input tree
Dec 06 13:43:02 <stormbytes> morning
Dec 06 13:45:02 <stormbytes> not having any luck getting anything out of the serial port on P2.11/13. I've enabled the port as uart (config-pin p9.11 uart, config-pin p9.13 uart) and I've added a line to /dev/boot/uEnv.txt (cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5)
Dec 06 13:45:51 <stormbytes> i've got an ftdi connected to my computer and wired up to ground, tx, rx on the bbb.
Dec 06 13:46:00 <stormbytes> what am i missing?
Dec 06 13:46:39 <stormbytes> oh and i'm opening up a terminal on the BBB using 'sudo picocom /dev/ttyO4'
Dec 06 14:17:47 <stormbytes> so i was able to get Uarts 1 & 2 to work (pins p9.21/22, p9.24/26) but no luck with p9.11/13 which is supposed to be Uart4. Config-pin -q doesn't even show it as a Uart... very confusing indeed
Dec 06 14:25:22 <zmatt> stormbytes: uhh, the capemgr stuff in /boot/uEnv.txt is inappropriate in this context
Dec 06 14:25:32 <zmatt> it's mutually exclusive with using config-pin
Dec 06 14:25:43 <stormbytes> so i can just delete that addition
Dec 06 14:26:31 <stormbytes> it wasn't doing anything anyway
Dec 06 14:26:33 <zmatt> it sounds like it just got ignored in your case, probably since u-boot overlays are being used, but otherwise they would actually have made config-pin not work
Dec 06 14:26:55 <zmatt> you're saying uart 4 (ttyS4) isn't being enabled? lemme check
Dec 06 14:26:59 * stormbytes nods politely
Dec 06 14:27:14 <stormbytes> uart4 isn't coming up on pins 11/13
Dec 06 14:27:56 <stormbytes> i've got uarts 1 & 2, which is fine.. but i this board is supposed to have 4 uarts and 1 tx only afaik
Dec 06 14:28:11 <stormbytes> i'm working with an older BBB rev-c
Dec 06 14:28:25 <stormbytes> should be getting my brand spanking new BBB-W replacement within the hour
Dec 06 14:28:30 <stormbytes> will try not to fry this one lmao
Dec 06 14:29:19 <zmatt> they have the same expansion headers anyway
Dec 06 14:30:21 <stormbytes> I added this to /boot/uEnv.txt "cape_enable=capemgr.enable_partno=BB-UART1,BB-UART2,BB-UART4,BB-UART5"
Dec 06 14:30:38 <zmatt> yes, so please remove that again
Dec 06 14:30:39 <stormbytes> was that necessary ? i have no idea what i'm doing at this point..
Dec 06 14:30:50 <stormbytes> so get rid of that too?
Dec 06 14:30:53 <stormbytes> ok
Dec 06 14:30:55 <zmatt> "too" ?
Dec 06 14:31:05 <zmatt> you didn't mention any other /boot/uEnv.txt changes
Dec 06 14:31:52 <stormbytes> i searched around and found those 2 additions
Dec 06 14:32:05 <zmatt> 15:25 < zmatt> it's mutually exclusive with using config-pin
Dec 06 14:32:07 <stormbytes> i commented it out. rebooting now
Dec 06 14:32:14 <stormbytes> ok
Dec 06 14:32:31 <stormbytes> i'm happy to use config-pin its more intuitive
Dec 06 14:34:07 <zmatt> try adding to the kernel parameters ("cmdline" in /boot/uEnv.txt): 8250.nr_uarts=5
Dec 06 14:34:48 <zmatt> or 6 if you want to use uart5 (in which case you also need to disable video, there's an option for that in /boot/uEnv.txt )
Dec 06 14:36:12 <stormbytes> i'm confused
Dec 06 14:36:29 <stormbytes> so boot/uEnv.txt *is* relevant?
Dec 06 14:37:04 <stormbytes> what does boot/uEnv.txt do exactly? and what does config-pin do?
Dec 06 14:37:23 <zmatt> uhh, my suggestion is a very different change to /boot/uEnv.txt than what you did though
Dec 06 14:37:46 <zmatt> /boot/uEnv.txt contains config vars for the bootloader (u-boot)
Dec 06 14:38:18 <stormbytes> i don't know much at all about the inner workings of linux
Dec 06 14:38:55 <stormbytes> i'm confused
Dec 06 14:39:26 <stormbytes> in order to enable uarts, i need to add a config string to boot/uEnv AND use config-pin to set that pin as uart?
Dec 06 14:39:38 <zmatt> for some obscure reason unknown to me, the 8250 serial driver needs to know at initialization time how many instances it needs to make
Dec 06 14:40:03 <stormbytes> ok... and therefore
Dec 06 14:40:04 <zmatt> which can be set via the kernel parameter 8250.nr_uarts
Dec 06 14:40:41 <zmatt> since the kernel parameters are passed to the kernel by u-boot, you customize them in u-boot's config file
Dec 06 14:41:00 <zmatt> specifically the "cmdline" variable
Dec 06 14:41:35 <zmatt> which is already being set in /boot/uEnv.txt, so you just add additional kernel parameters to it
Dec 06 14:41:57 <stormbytes> ugh
Dec 06 14:42:23 <zmatt> just locate the line starting with "cmdline=" and append " 8250.nr_uarts=5" to the end of it
Dec 06 14:42:27 <stormbytes> zmatt i don't know squat bout kernels man :) i just want to know how to get the ports working
Dec 06 14:42:55 <stormbytes> and right now i'm back to zero activity on the ports that were working half an hour ago and i'm about ready to throw this fucking board into a blender
Dec 06 14:43:07 <stormbytes> this is why arduinos are so much more popular
Dec 06 14:43:09 <zmatt> uhh, what did you do?
Dec 06 14:43:39 <zmatt> config-pin should work for any port for shows up as a /dev/ttyS* device
Dec 06 14:43:54 <stormbytes> i edited out /etc/default/capemgr (which shoudln't have many any difference as it only had a reference to uart4 which never worked anyway)
Dec 06 14:44:29 <zmatt> okay, hopefully that file is just being ignored
Dec 06 14:44:58 <stormbytes> and what i don't understand for the life of me is how in ~ 7 years that the Beaglebone has been out, in one form or another, no genius has managed to write a book on the friggin board thats purely iOT centric
Dec 06 14:45:19 <zmatt> any such book would have been obsolete and useless within a few months
Dec 06 14:45:50 <zmatt> unfortunately a lot of stuff has taken quite a bit of time to stabilize
Dec 06 14:46:56 <zmatt> to get an uart working on the latest image, all you should need is configuring the pins using config-pin
Dec 06 14:47:07 <zmatt> and uncommenting 'disable_uboot_overlay_video=1
Dec 06 14:47:09 <zmatt> '
Dec 06 14:47:12 <zmatt> if you want to use uart5
Dec 06 14:47:29 <stormbytes> i tried that
Dec 06 14:47:31 <zmatt> (since uart5 conflicts with video output)
Dec 06 14:47:33 <stormbytes> well.. i tried a lot of things
Dec 06 14:47:42 <zmatt> yes, that's what I'm worried about :)
Dec 06 14:47:44 <stormbytes> i'm gonna try and see wtf this isnt' working onow
Dec 06 14:47:52 <stormbytes> well actually not a 'lot' of things
Dec 06 14:48:10 <stormbytes> 1. i added a line to /etc/default/capemgr - which i have since deleted (and rebooted)
Dec 06 14:48:27 <stormbytes> 2. i added a line to /boot/uEnv.txt - which I have since commented out
Dec 06 14:48:35 <stormbytes> other than that i just set my pins to Uart
Dec 06 14:48:51 <zmatt> which /dev/ttyS* devices appear?
Dec 06 14:49:11 <stormbytes> oh fuck me.. now p9.21 doesn't even appear as UART
Dec 06 14:49:33 <zmatt> what do you mean? config-pin no longer works?
Dec 06 14:49:38 <stormbytes> 0-1-2-3-4
Dec 06 14:49:54 <stormbytes> config pin works, but it no longer shows p9.21 as a uart
Dec 06 14:50:02 <zmatt> what do you mean
Dec 06 14:50:03 <zmatt> ?
Dec 06 14:50:06 <stormbytes> config-pin -q  p9.21
Dec 06 14:50:26 <stormbytes> → pin -q p9.21
Dec 06 14:50:27 <stormbytes> P9_21 Mode: default Direction: in Value: 0
Dec 06 14:50:38 <zmatt> just checking: you realize config-pin is not persistent across reboots?
Dec 06 14:50:58 <stormbytes> no i didn't realize that
Dec 06 14:51:21 <stormbytes> either way.. its not even showing uart as an option now
Dec 06 14:51:35 <stormbytes> so something seriously b0rked
Dec 06 14:52:15 <zmatt> are you sure you've undone the changes you did?
Dec 06 14:52:25 <stormbytes> i'm checking it over now
Dec 06 14:53:26 <stormbytes> ok it works again.. that's what it was
Dec 06 14:53:31 <stormbytes> weird as hell
Dec 06 14:53:58 <stormbytes> previously (i'm pretty sure) when i used config-pin -q p9.xx it gave me a bunch of 'options' for that pin
Dec 06 14:54:30 <stormbytes> after the reboot it didn't do that anymore, however when i set the pin to UART again it and opened another terminal session it worked fine
Dec 06 14:54:49 <stormbytes> very weird..
Dec 06 14:55:06 <stormbytes> BBB needs to address documentation rather than focusing on more hardware
Dec 06 14:56:52 <stormbytes> ok that was it...
Dec 06 14:56:53 <zmatt> yup
Dec 06 14:57:01 <stormbytes> uart4 is working as well
Dec 06 14:57:11 <zmatt> problem is that there's quite a bit of obsolete info on the web
Dec 06 14:57:19 <zmatt> which is adding a lot of confusion
Dec 06 14:57:21 <stormbytes> you're tellin me
Dec 06 14:57:50 <stormbytes> the problem with bbb is that its obviously lacks experienced management
Dec 06 14:58:14 <zmatt> I don't feel qualified to judge that
Dec 06 14:58:29 <stormbytes> they've got a bunch of engineers, community contributors and probably Ti throwing money at them for being the dev board for the Sitara
Dec 06 14:58:45 <stormbytes> zmatt  you don't need to be a meteorologist to know that its raining
Dec 06 14:59:02 <zmatt> it could definitely be friendlier for newcomers, but it may be a simple lack of time/resources
Dec 06 14:59:19 <stormbytes> i'm not asking for 'friendly'. I'm saying it needs an organized presentation
Dec 06 14:59:55 <stormbytes> it doesn't have to be 'dumbed down' or simplified... i hate the GUI crap rpi has going on... but it needs to be centrally documented and this is one area in which BBB has made exactly zero headway in 7+ years
Dec 06 15:00:58 <zmatt> you won't hear me disagreeing
Dec 06 15:01:32 <zmatt> although that is what I mean by "friendlier for newcomers"
Dec 06 15:01:35 <stormbytes> any experienced project manager would spot that straight away
Dec 06 15:01:39 <stormbytes> fair enough
Dec 06 15:02:21 <stormbytes> this is no-brainer material. I'm actually working (well. 'fumbling' lol) through a prototype for a commercial project. I have the user's experience front-and-center in EVERY design consideration
Dec 06 15:02:26 <zmatt> oldtimers like me have settled in some way of using the bbb that works, so I don't really experience the lack of documentation except through helping newcomers
Dec 06 15:03:14 <stormbytes> and i appreciate your help very much. Frankly, i'd be stumped without it. :)
Dec 06 15:03:50 <stormbytes> but that's not a very good merchandizing strategy for a company that sells boards at $60-100/each through global distribution
Dec 06 15:04:05 <zmatt> you're welcome :)  fortunately I've absorbed enough knowledge of how the standard image and tools like config-pin work to be able to reproduce it.... I don't use them at all myself
Dec 06 15:04:17 <stormbytes> 'community' is a great word for github, but this is a for-sale product
Dec 06 15:04:42 <stormbytes> what's your poison of choice?
Dec 06 15:04:49 <stormbytes> ... if not bbb->iOt
Dec 06 15:05:37 <zmatt> we use custom debian-based images, and a custom device tree depending on the product in which the bbb gets integrated (no overlays or runtime pin config))
Dec 06 15:07:04 <stormbytes> so you build stuff atop the bbb?
Dec 06 15:07:22 <stormbytes> oh yea i think you mentioned a while back... i asked why you don't use the beaglecore or something similar
Dec 06 15:08:09 <zmatt> their site sucks
Dec 06 15:08:12 <zmatt> ;D
Dec 06 15:09:53 <stormbytes> who bc?
Dec 06 15:09:58 <zmatt> also, that thing looks awful to integrate, and it's not particularly cheap
Dec 06 15:10:26 <stormbytes> hah
Dec 06 15:10:32 <zmatt> being able to run the bbb standalone is quite convenient and something we currently use for programming them before integration
Dec 06 15:10:39 <stormbytes> if you're building products atop the sitara platform why not just make your own?
Dec 06 15:11:18 <stormbytes> and question: before i forget. if all config-pin settings are wiped out at each reboot (which is level 5 moronic) how do you persist these?
Dec 06 15:11:28 <zmatt> that's an option we may move toward in the future, but it's quite expensive to do so in low quantity
Dec 06 15:11:42 <stormbytes> how much of the BBB are you actually using?
Dec 06 15:12:44 <zmatt> one of the hw guys once checked for a price quote on the bbb's pcb (unmodified) and I got the impression he was slightly intimidated by the answer
Dec 06 15:13:05 <stormbytes> you could always subsidize your development by selling the part, thereby possibly recouping some of your investment.. though easier said
Dec 06 15:13:32 <zmatt> very unlikely, that would imply we'd recreate a generic beaglebone-like product, which would be utterly pointless
Dec 06 15:14:06 <stormbytes> I disagree.. i think there's no shortage of demand for linux-driven arduino-like product
Dec 06 15:14:22 <stormbytes> i think BC was on the right track but their execution was terrible
Dec 06 15:14:32 <stormbytes> that whole mother-daughter board thing... pointless
Dec 06 15:14:54 <zmatt> if you feel you can do better, go for it... the bbb hw design is open
Dec 06 15:14:59 <stormbytes> they should have made a business card sized BBB with a sitara chip and a buch of I/o's
Dec 06 15:15:19 <stormbytes> i don't have the engineering expertise but as far as marketing goes? hands down
Dec 06 15:15:37 <stormbytes> BC created a solution in search of a problem
Dec 06 15:16:28 <stormbytes> you need to 1. create the device and 2. demonstrate a handful of practical use cases, *especially* using nodejs
Dec 06 15:16:46 <stormbytes> the pitch is simple, cheap iOT with NodeJS.
Dec 06 15:17:31 <zmatt> except that's too vague, and in that vague category it's definitely not the cheapest
Dec 06 15:17:47 <stormbytes> it doesn't have to be the cheapest
Dec 06 15:18:02 <stormbytes> a $50 board would sell just fine as long as the use cases were clearly defined
Dec 06 15:18:48 <zmatt> anyway, I fully agree that the bbb could use a better "presentation"... but I'm the wrong person to talk to about that
Dec 06 15:18:57 <stormbytes> fair enough
Dec 06 15:19:04 <stormbytes> as long as my uarts are working lol
Dec 06 15:19:12 <stormbytes> which they all now appear to be
Dec 06 15:19:20 <stormbytes> so how do i persist my config-pin settings?
Dec 06 15:19:43 <stormbytes> or do i need to run a script at boot that sets them each time
Dec 06 15:19:50 <zmatt> with config-pin, yeah basically
Dec 06 15:19:59 <stormbytes> ugh
Dec 06 15:20:09 <zmatt> that's one of its disadvantages
Dec 06 15:20:25 <stormbytes> there's no way to simply 'set' the pins to uart forever
Dec 06 15:20:33 <stormbytes> why in the world....
Dec 06 15:21:44 <zmatt> a better way to produce a custom dtb is something I think would be highly desirable... but meanwhile I've gotten good enough at hand-writing dts that I always have other stuff that's higher-priority to me
Dec 06 15:22:33 <stormbytes> dts?
Dec 06 15:22:52 <zmatt> device tree source
Dec 06 15:23:09 <stormbytes> i'm not familiar
Dec 06 15:23:52 <zmatt> the kernel is informed about the hardware via a data structure called a "device tree", which is provided to it in a serialized format by u-boot
Dec 06 15:24:19 <stormbytes> i see
Dec 06 15:24:35 <zmatt> u-boot obtains it by reading a .dtb file, and since recent time it also loads and applies various "overlays" (from .dtbo files)
Dec 06 15:24:36 <stormbytes> so the dts is what you change with config-pin
Dec 06 15:24:41 <zmatt> no
Dec 06 15:25:23 <zmatt> runtime changes to the device-tree was the old way
Dec 06 15:25:37 <zmatt> that's what capemgr is/was for
Dec 06 15:25:49 <stormbytes> ah
Dec 06 15:25:57 <stormbytes> what does config-pin change?
Dec 06 15:27:45 <zmatt> "cape-universal" (which is the thing for which config-pin is the control utility) basically enables all peripherals in DT and declares all possible pinmux options there, and for each pin it instantiates a pseudo-device (driver "bone-pinmux-helper") responsible for allowing userspace to select the pinmux for that pin
Dec 06 15:28:09 <zmatt> it's actually pretty horrid, but it has a high degree of user convenience
Dec 06 15:29:12 <zmatt> see https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/univ-bbb-EVA-00A0.dts
Dec 06 15:29:26 <stormbytes> ok, :) i think i'll just whip up a quick bash scrip, drop it into /etc/init.d and be done
Dec 06 15:29:42 <zmatt> you can use /etc/rc.local
Dec 06 15:29:52 <stormbytes> does the same thing?
Dec 06 15:30:40 <stormbytes> i don't see an rc.local
Dec 06 15:30:54 <zmatt> hmm, did they get rid of it?
Dec 06 15:31:05 <zmatt> I mean, I did, but I thought it was still prevent on the default images
Dec 06 15:31:19 <zmatt> *present
Dec 06 15:31:26 <stormbytes> i guess.. i just checked
Dec 06 15:32:16 <zmatt> then yeah you can use an old-style /etc/init.d script, they're still supported via a compatibility layer
Dec 06 15:34:34 <stormbytes> man this *nix stuff is pretty involved
Dec 06 15:34:49 <stormbytes> i'm just looking for a smarter, easier to program Arduino :)
Dec 06 15:35:18 <stormbytes> one with a full network stack, nodejs event model
Dec 06 15:35:24 <zmatt> having a full linux system has the unfortunate side-effect of having a full linux system
Dec 06 15:35:30 <stormbytes> hahaha
Dec 06 15:36:10 <stormbytes> well hopefully one day there will be  more differentiated images (think AMIs) for these boards
Dec 06 15:36:33 <stormbytes> so you *know* you're getting exactly as much prefab boilerplate as you need and don't need to hassle with any of it
Dec 06 15:36:40 <stormbytes> total waste of time, imo
Dec 06 15:38:13 <stormbytes> is there a way to read what the pins are currently set to?
Dec 06 15:38:30 <zmatt> big downside of nodejs though: it's so obese and slow
Dec 06 15:38:44 <zmatt> especially once you install one or two npm packages... (  http://www.monkeyuser.com/assets/images/2017/52-npm-delivery.png )
Dec 06 15:39:08 <Maksym> Hy guys, can some help mee with reading the data from MPU6050 to BBBW?
Dec 06 15:39:16 <zmatt> stormbytes: you may find my show-pins utility nice for that, found at https://github.com/mvduin/bbb-pin-utils
Dec 06 15:39:21 <Maksym> i can't find some code
Dec 06 15:39:36 <stormbytes> coolness! thanks zmatt
Dec 06 15:39:46 <zmatt> Maksym: doesn't it have a kernel driver?
Dec 06 15:39:53 <Maksym> yes
Dec 06 15:40:05 <Maksym> i think :p
Dec 06 15:40:14 <zmatt> yeah it definitely does
Dec 06 15:40:50 <Maksym> i can't find a code to read my SCL & SDA pin in bonescript
Dec 06 15:41:19 <zmatt> so you don't want to use the kernel driver?
Dec 06 15:41:55 <Maksym> i wanna use it if it will help
Dec 06 15:42:03 <stormbytes> zmatt very cool utility !!
Dec 06 15:42:11 <Maksym> how can i do that?
Dec 06 15:45:52 <zmatt> Maksym: it should be possible to instantiate the driver via sysfs... something like   echo mpu6050 0x68 >/sys/bus/i2c/devices/i2c-2/new_device    assuming it's connected to i2c bus 2 and has slave address 0x68
Dec 06 15:48:25 <zmatt> stormbytes: yeah I'm pretty happy with it :)
Dec 06 15:48:54 <zmatt> and I even documented it semi-recently
Dec 06 15:49:46 <stormbytes> and semi-decently too :)
Dec 06 15:51:22 <zmatt> spotted a small error in the readme though
Dec 06 15:52:30 <zmatt> fixed
Dec 06 16:41:13 <clockman> alright, so I have been on this issue before. But I don't know how to go about finding the cause of the problem - every once in a while, I have a BBB/BBBW/BBG that won't boot. I connect to debug, and it gives me "rootfs: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY." then kicks me to the initramfs. I am sitting here with a BBBW that is giving me this error and I don't want to manually run fsck until I can find out WHAT cause
Dec 06 16:41:13 <clockman> s the problem (or a hint of it). Can anyone point me give a tip of what exactly I should look for?
Dec 06 16:44:46 <clockman> I've already run 10 passes of badblocks on another one that crapped out like this and it gave me 0/0/0 errors, so I don't think the issue is a bad flash chip. (that plus the problem has happened numerous times to numerous different boards)
Dec 06 17:40:54 <kuncarlos> Hello, after deploying applications to beaglebone black using the linx labview I am unable to connect to the beaglebone, no access to 192.168.7.2, any advise?
Dec 06 17:58:27 <shiva_> Hi :). I am new to BBB. I am trying to read an eQEP encoder, and I cannot find the 'slots' file in bone_capemgr
Dec 06 17:58:37 <shiva_> Could you please help? :(
Dec 06 18:00:09 <shiva_> @pdp7
Dec 06 18:19:11 <zmatt> shiva_: if you're running a recent image, you don't need to meddle with capemgr at all
Dec 06 18:19:49 <zmatt> the qep peripherals should already be enabled, all you need to do is configure the pins using the config-pin utility
Dec 06 18:21:43 <shiva_> @zmatt Let me check. Thank you!
Dec 06 18:29:36 <shiva_> @zmatt ubuntu@arm:/sys/devices/platform/ocp/48304000.epwmss/48304180.eqep$ tail -f position 0
Dec 06 18:29:52 <shiva_> I cannot read the encoder position
Dec 06 18:38:33 <zmatt> did you configure the pins to eqep function using config-pin
Dec 06 19:44:52 <Maksym> some 1 already used MPU6050 as accelerometer?
Dec 06 19:46:22 <Maksym> i'm trying to use this guid but... https://www.npmjs.com/package/mpu6050
Dec 06 21:57:05 <stormbytes> zmatt
Dec 06 21:57:08 <stormbytes> question:
Dec 06 21:57:45 <stormbytes> i used my xbeen shield for tx/rx with my BBB and it worked fine (its a 5V shield but the i/o might be 3.3V)
Dec 06 21:57:55 <stormbytes> is it fair to assume it would work fine with the BBB-W as well?
Dec 06 21:58:01 <stormbytes> xbee not xbeen
Dec 06 22:24:29 <arbaaz_> I'm trying to make a rgb fade with random colour, for random durations, fading from one colour to the next but I cant the random part of the program to work
**** ENDING LOGGING AT Thu Dec 07 03:00:01 2017