**** BEGIN LOGGING AT Tue Apr 03 03:00:02 2018
Apr 03 03:39:18 <fortnight> Um, I had to use sudo on line 34. I added rc.local and then retyped line 13 after line 23 was typed out on the terminal.
Apr 03 06:45:03 <Peter___> Anyone have experience with Beagleboard wireless and Bela Cape?
Apr 03 06:50:10 <Guest48933> Hi, I could use some help, I have a standard beagleboard X15, and I don't know which Hirose FX18 connector to use for the GPIO plugs
Apr 03 06:58:13 <krissmaster> Hola. Which PCIe adapter works with the x-15?
Apr 03 07:03:43 <tbr> I'm not aware of an off the shelf adapter for it, maybe there is though
Apr 03 07:04:30 <tbr> Guest48933: have you looked at the System Reference Manual for the X15. IIRC it lists several part numbers
Apr 03 07:07:01 <Guest48933> I've gone through the SRM and there's a few different ones, I'm looking for the right plug that works with the FX18-60P-0.8SV
Apr 03 07:13:18 <tbr> sorry, no idea. you could also ask on the google group. https://groups.google.com/forum/#!forum/beagleboard-x15
Apr 03 09:31:06 <sri__> hi iam facing problem in beaglebone black u-boot
Apr 03 09:31:57 <sri__> TFTP,UMS,SAVEENV commands are not found
Apr 03 09:33:20 <sri__> if i do some changes in the menuconfig it produce some error message but without any changes in menuconfig its compiling normally
Apr 03 09:38:34 <tbr> sri__: try asking on the U-Boot IRC channel
Apr 03 09:41:07 <sri__> ok thank you
Apr 03 10:27:21 <zmatt> odd, I though tftp and ums were enabled by default
Apr 03 11:32:47 <drift> chaps a daft q. where can i customise the board and who would could build it for me please?
Apr 03 11:34:44 <pappu> hi
Apr 03 11:35:04 <pappu> can anybody help me in getting this information
Apr 03 11:35:19 <pappu> n website , https://beagleboard.org/black-wireless  it is mentioned 3rd party android support for BB wireless.  please let me know , which 3rd party supports it and from where to download the android source and steps to build it .
Apr 03 11:38:16 <LetoThe2nd> pappu: https://eewiki.net/display/AOA/BeagleBone+Black seems to be maintained, so go for it.
Apr 03 11:42:00 <pappu> actually this is for Beaglebone black
Apr 03 11:42:12 <pappu> i was looking for beaglebone black wirelss
Apr 03 11:42:16 <pappu> wireless
Apr 03 11:42:55 <tbr> same thing, just with wifi glued on
Apr 03 11:43:22 <LetoThe2nd> same cpu, same rest.... start with the bbb build and beat it into shape. i doubt that anybody already prepared it.
Apr 03 11:43:30 <pappu> and it looks like BB is not available for immediate delivery
Apr 03 11:43:42 <pappu> as it is quite old board now
Apr 03 11:43:57 <tbr> any BBB image will run on the BBB-wireless too
Apr 03 11:46:02 <LetoThe2nd> if i wanted android, i'd probably go for a dragonboard anyways. or something along those lines.
Apr 03 11:46:23 <tbr> or hikey, they even have AOSP reference status
Apr 03 11:46:27 <pappu> yes android is what i am looking for
Apr 03 11:46:29 <LetoThe2nd> tbr: ++
Apr 03 11:47:11 <tbr> also I'd imagine that Android on the BBB SoC would not be much fun
Apr 03 11:47:58 <LetoThe2nd> tbr: but but.... but.... ANDROID!
Apr 03 11:47:59 <pappu> i want AOSP to rebuild and good open source support for it in terms of SW and hardware ( datasheets should be open)
Apr 03 11:48:28 <pappu> so can u guys suggest me some good board for android specifically
Apr 03 11:48:37 <LetoThe2nd> and immediate delivery, and everything already prepared :-D
Apr 03 11:49:35 <tbr> .oO(drei wuensche auf ein mal!!!!einself!)
Apr 03 11:49:49 <LetoThe2nd> tbr: here, have some schoggi.
Apr 03 11:50:03 <tbr> nomnomnom :-D
Apr 03 11:50:58 <pappu> 1st recommendation is dragonboard . which board i should explore from hikey
Apr 03 11:51:40 <LetoThe2nd> pappu: https://www.96boards.org/product/hikey/
Apr 03 11:52:18 <LetoThe2nd> pappu: please be aware that this is in fact the beagleboard channel, and not the place to do your homewo... erm, research.
Apr 03 11:52:57 <pappu> yes i agree
Apr 03 11:54:03 <pappu> thanks everybody for the information
Apr 03 11:54:16 <tbr> there's also HiKey960 and I think 970 too?
Apr 03 11:54:59 <thinkfat> the 96boards are actually very sucky regarding software development
Apr 03 11:55:20 <thinkfat> like, no ethernet, no u-boot, ...
Apr 03 11:55:38 <thinkfat> horrible uefi boot...
Apr 03 11:56:33 <tbr> but but but Linarooooo! :D
Apr 03 11:56:59 <thinkfat> death by best intentions
Apr 03 11:58:31 <thinkfat> the idea to have not one but two full size usb connectors (plus one OTG), full size HDMI but no place for an ethernet jack, ...
Apr 03 12:00:56 <zmatt> does it have an ethernet peripheral?
Apr 03 12:01:35 <zmatt> since it's apparently a smartphone/tablet SoC so it's far from obvious it has any reason to have ethernet
Apr 03 12:03:43 <thinkfat> a - it's useless trying to cram a 96board into a tablet or smartphone case and sell that
Apr 03 12:04:01 <zmatt> ??
Apr 03 12:04:31 <thinkfat> b - as it's obviously a development platform, it should make development easy and painless
Apr 03 12:04:59 <zmatt> true. they could have added some crappy usb-ethernet chip like the rpi and omap5-uevm do
Apr 03 12:06:46 <thinkfat> also, if it's for smartphones and tables, why add a "sensor cape" to the ecosystem which even has its own atmega micro controller (since apparently the main soc is not up to snuff for i/o tasks)
Apr 03 12:44:51 <tbr> 96borads was a trainwreck from the very beginning
Apr 03 14:28:00 <Technicus> Hello.
Apr 03 14:30:55 <Technicus> I have a pocket beagle and connected it to a linux machine via usb.  I was able to ssh into it, but not access internet from it.  I tried setting up a network address translation configuration with ip tables to forward internet traffic, but I screwed it up.  Now I can not ssh into it.
Apr 03 14:31:24 <Technicus> I'm not that good with network configurations.  Will someone give me some suggestions on how to set it up?
Apr 03 14:38:44 <keesj> is it for serious work?
Apr 03 14:40:03 <Technicus> It is a project I am working on.
Apr 03 14:43:27 <keesj> this is not beagle specific but works on almost any machine you have ssh access to https://mm.mmapps.net/wiki/SysAdmin . else you might want to simply run a http proxy or similar on your development pc and do you network access over http proxy. If you want the "real" thing (with nat) I can not help
Apr 03 14:44:05 <Technicus> I am trying to make it into an audio device, maybe a looper, or mp3 player, or possibly a synthesizer.
Apr 03 14:47:56 <Technicus> I am also trying to figure out how to connect the pocket beagle to < https://www.mikroe.com/audio-codec-proto-board > via i2s or whatever protocol possible.
Apr 03 15:05:26 <Technicus> Ok, nevermind about the network connection, I have that working.  Thanks!!!  . . . . but I'm still scratching my head about connecting an i2s audio device.  Any suggestions?
Apr 03 15:05:55 <zmatt> Technicus: I'm happy to report: it is possible
Apr 03 15:06:16 <zmatt> (I'm a bit too busy to explain right now unfortunately)
Apr 03 15:07:32 <Technicus> AWESOME!!!!!
Apr 03 18:03:50 <kenrestivo> i'd love to have lineageos running on bbb
Apr 03 18:03:59 <kenrestivo> project for my copious spare time, maybe.
Apr 03 18:11:10 <Guest79759> Hi there, I followed the instructions here (https://github.com/beagleboard/pocketbeagle/wiki/FAQ#how-do-i-get-additional-usb-connections) to add a usb port to my Pocket Beagle. I have a USB device plugged into the additional usb port (incidentally it’s a USB->Ethernet adapter). So the usb device is relying on the Pocket Beagle tosupply power to it. Is it true that the Pocket Beagle needs to be plugged in to a usb host via it’s main US
Apr 03 18:11:11 <Guest79759> port in order for it to provide power to teh USB device that’s plugged in to it’s extra usb port?
Apr 03 18:38:52 <tbr> no clue about the pocket, but the regular one needs either 5V through the barrel connector or via USB
Apr 03 18:41:49 <zmatt> Technicus: ah, that codec actually has a linux driver
Apr 03 18:42:55 <Technicus> Cool! Is there a connection diagram anywhere?
Apr 03 18:43:43 <Technicus> zmatt: Will you send me a link?
Apr 03 18:44:09 <zmatt> hold on I'm still reading up on that breakout board you have
Apr 03 18:44:43 <zmatt> plus you'll need to customize the device tree since the pocketbeagle doesn't use u-boot overlays yet
Apr 03 18:45:30 <Technicus> Cool, this is adding up to be a challenge.
Apr 03 18:53:01 <Guest79759> Thanks @tbr. yea I guess my question is specific to the pocket beagle. It doesn’t have a barrel connector but I’m powering it with 5V on the VIN pin. It appears that that’s not sufficient to power the usb device I have connected to the secondary usb pins. I’m wondering how best to power the usb device when the pocket beagle isn’t plugged in to a usb host via it’s main port. I’m thinking I probably need to provide 5V to the U
Apr 03 18:53:01 <Guest79759> VBUS pin (P1_05) but would really appreciate if anyone could confirm that that’s correct.
Apr 03 18:53:38 <tbr> paging jkridner
Apr 03 18:54:00 <jkridner> wassup?
Apr 03 18:54:51 <jkridner> Guest79759: depends on how you have the power hooked up on the "secondary" pins and what the consumption is.
Apr 03 18:55:38 <jkridner> Guest79759: I do this: https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#73_Setting_up_an_additional_USB_Connection
Apr 03 18:55:54 <jkridner> it works for most USB devices, again, depending on their power consumption.
Apr 03 18:56:34 <jkridner> zmatt: you can use u-boot overlays with PocketBeagle and the latest images.
Apr 03 18:56:54 <jkridner> zmatt: do you mean mainline u-boot?
Apr 03 18:57:48 <Guest79759> thanks @jkridner, that link you sent is exactly what I’ve done. It works great as long as the PocketBeagle is connected via it’s main usb port. If it’s not plugged in via it’s main usb port and instead is powered via it’s VIN pin the usb device doesn’t seem to receive power
Apr 03 18:57:49 <zmatt> uh, this must have been fixed very recently then?
Apr 03 18:58:57 <jkridner> not that recently... all this year.
Apr 03 18:58:58 <zmatt> jkridner: I don't see a -uboot version of the pocketbeagle dts in the 4.9-ti branch of dtb-rebuilder (nor the 4.14-ti one)
Apr 03 18:59:06 <Guest79759> which makes sense, the PocketBeagle likely doesnt have a 5V regulator so it would have no way to provide 5V to the USB device unless it’s plugged in to a USB host such as a laptop
Apr 03 18:59:11 <jkridner> it works differently....
Apr 03 18:59:21 <jkridner> the overlays hack the full version...
Apr 03 18:59:28 <jkridner> rather than building up from a minimal version.
Apr 03 18:59:44 <zmatt> ew
Apr 03 18:59:48 <zmatt> ok
Apr 03 19:00:07 <zmatt> yeah I guess it can work
Apr 03 19:00:16 <jkridner> see https://jkridner.wordpress.com/2018/01/17/building-a-device-tree-overlay-for-your-new-pocketcape-design/
Apr 03 19:02:38 <Technicus> Here is something relatively similar to what I am attempting to configure: < http://www.malinov.com/Home/sergey-s-blog/inteledison-simplei2saudiosetup >, < http://www.malinov.com/Home/sergeys-projects/audio-block-for-intel-edison >.
Apr 03 19:03:15 <zmatt> fair enough... I just didn't think of partially overriding the cape-universal stuff because on beaglebones u-boot actually still disables cape-universal if you ask it to load an overlay
Apr 03 19:05:30 <Guest79759> Thanks for your help @jkridner, when you say “it works for most usb devices” is that with the assumption the the PocketBeagle is plugged in to a USB host via it’s main USB socket? In cases where the PocketBeagle is not powered via USB but by its VIN pin should we expect a USB device that is connected as described here: https://github.com/beagleboard/pocketbeagle/wiki/System-Reference-Manual#73_Setting_up_an_additional_USB_Connection
Apr 03 19:05:31 <Guest79759> receive power?
Apr 03 19:06:52 <Guest79759> And if not, is it ok for me to provide 5V to the VBUS pin (P1_05) to power the USB device?
Apr 03 19:38:48 <zmatt> Technicus: here's at least my best guess at the DT nodes for audio... https://pastebin.com/raw/ggKMR4Nh
Apr 03 19:38:51 <zmatt> bbl
Apr 03 19:41:40 <zmatt> actually nm, it's wrong, nevertheless bbl
Apr 03 19:55:56 <Technicus> zmatt: !!!!
Apr 03 19:57:56 <Technicus> Where can I go to learn the syntax of device tree overlays.
Apr 03 19:59:53 <Technicus> zmatt: Thanks a lot.
Apr 03 20:02:06 <Technicus> I want to really understand device tree overlays.  It is still a big mystery to me.
Apr 03 20:02:18 <Technicus> I am slowly beginning to understand.
Apr 03 20:09:17 <kenrestivo> it's... an unnecessarily complicated beast
Apr 03 20:09:24 <kenrestivo> but the basics aren't that hard to grasp.
Apr 03 20:13:06 <Technicus> Where do I go to get started learning?
Apr 03 20:14:28 <Technicus> zmatt: where can I go to learn about the wm8731 driver?
Apr 03 20:15:23 <Technicus> Here it is: < https://github.com/torvalds/linux/blob/master/sound/soc/codecs/wm8731.c >.
Apr 03 20:20:28 <zmatt> Technicus: well, device tree overlays are just chunks of device tree that are patched onto the main device tree (formerly at runtime, nowadays by u-boot before the DT is passed to the kernel)
Apr 03 20:21:21 <zmatt> overlays themselves actually have a bit icky format, but my https://github.com/mvduin/overlay-utils can hide that ugly detail
Apr 03 20:21:49 <zmatt> audio is unfortunately one of the more complicated things to set up
Apr 03 20:22:28 <Technicus> zmatt: Hummmm . . . . will you enlighten me as to what u-boot is?  Also, I'm not sure what pins I should connect the audio codec to.
Apr 03 20:22:51 <zmatt> u-boot is the bootloader (/boot/uEnv.txt is its config file)
Apr 03 20:23:44 <zmatt> yeah I'll get to pins... I actually still need to read a bit more of the wm8731 datasheet to check some details
Apr 03 20:23:47 <Technicus> zmatt: Where can I learn more about the main device tree?
Apr 03 20:25:01 <zmatt> google can probably help you with that ;)   looking at the various examples in my overlay-utils might also be informative.  they're mostly small and simple, and often have comments
Apr 03 20:25:53 <zmatt> some syntax basics you'll need: &foo references a node labeled foo:
Apr 03 20:27:28 <zmatt> &foo {  stuff = <42>;  };     looks up an existing node labeled foo: and sets its "stuff" property to the 32-bit integer 42 (replacing any previous value of the "stuff" property if it already had it)
Apr 03 20:27:49 <zmatt> so each top-level block basically makes some change or addition to the overall tree
Apr 03 20:29:05 <Technicus> Sorry, I'm kind of lost.  What are the example overlay-utils you referenced and this &foo stuff you are getting at?  I need to go find a tutorial or something that will help me understand all of this.
Apr 03 20:29:19 <zmatt> the .dtsi files in https://github.com/mvduin/overlay-utils
Apr 03 20:29:37 <zmatt> browse them, hopefully what I just said will start making more sense
Apr 03 20:29:47 <zmatt> otherwise, indeed google for a device tree tutorial
Apr 03 20:30:39 <Technicus> zmatt: Are you mvduin?
Apr 03 20:30:43 <zmatt> yes
Apr 03 20:30:55 <Technicus> Okay, now I understand.
Apr 03 20:37:25 <zmatt> ...
Apr 03 20:37:26 <zmatt> ehh
Apr 03 20:37:37 <zmatt> oh god that's just fucking great /o\
Apr 03 20:38:06 <zmatt> god I hate ASoC.... everything always has to be more complicated
Apr 03 20:38:31 <zmatt> it looks like you're not going to get this thing working without a kernel patch
Apr 03 20:38:54 <zmatt> I'm still double-checking to see if I'm overlooking something
Apr 03 20:43:03 <zmatt> yeah, I'm not
Apr 03 20:46:34 <zmatt> the wm8731 driver requires a set_sysclk call with clk_id = 1 to enable the oscillator
Apr 03 20:46:44 <zmatt> the simple-audio-card driver hardcodes clk_id = 0
Apr 03 20:47:39 <zmatt> -.-
Apr 03 20:48:37 <zmatt> easiest workaround is probably just a one-line patch to the wm8731 driver to force clk_id to 1
Apr 03 20:53:18 <zmatt> extending simple-audio-card to support setting the clk_id to a different value might actually not even be that hard either, and would definitely score higher on elegance
Apr 03 20:55:12 <jkridner> Guest79759: the diagram I showed pulls power off of the USB micro-B connector and supplies it to the added connector/device. The "most" is really all about the power requirement.
Apr 03 21:12:45 <Guest79759> Thanks @jkridner. So for the case where the PocketBeagle is not plugged in to a usb host I’d need to find another way to supply power to the USB device. Does that make sense? Not sure if I’m explaining it well. That being the case, I’m thinking of connecting an external 5V supply to the VBUS pin (P1_05) to power the USB device. Does that sound like a good idea?
Apr 03 21:13:25 <zmatt> Technicus: I think this might be a good solution: https://github.com/dutchanddutch/bb-kernel/blob/am33x-v4.14/patches/drivers/sound/0003-ASoC-wm8731-support-osc-by-setting-sysclk-dir.patch
Apr 03 21:15:37 <jkridner> Guest79759: yes.
Apr 03 21:16:01 <Guest79759> ok great, thanks jkridner!
Apr 03 21:16:38 <zmatt> Technicus: I think that patch should allow this sound-card configuration to work: https://pastebin.com/raw/RNs7tbzx
Apr 03 21:17:05 <zmatt> now all that remains is mcasp config and pin-stuff ;)
Apr 03 21:23:39 <fortnight> @jkridner: Do you remember this gist: https://gist.github.com/jadonk/6080ca92d6e225eb89d33ad7744e1775#file-ardupilot_setup-sh?
Apr 03 21:23:46 <fortnight> ...
Apr 03 21:24:12 <fortnight> I was trying to set up arduCopter on the BBBlue but I am unaware of how that file may work w/in Debian on the BBBlue for now.
Apr 03 21:26:04 <fortnight> I typed that out b/c I have set up Mission Planner and it does not recognize my BBBlue as a Linux Device/BBBlue.
Apr 03 21:26:05 <fortnight> ...
Apr 03 21:26:22 <fortnight> Should I skip Mission Planner? Who knows?
Apr 03 21:29:20 <fortnight> brb...tacos!
Apr 03 21:34:42 <fortnight> Sorry.
Apr 03 21:34:48 <fortnight> I lied. No tacos.
Apr 03 21:35:37 <fortnight> So, I see in the gist on GitHub that it is a file of some sort, i.e. .sh file. There are two shebangs in that file.
Apr 03 21:35:54 <fortnight> It makes me think that they are commands and not one, single file. Am I wrong?
Apr 03 21:40:37 <jkridner> fortnight: yeah, I remember it.
Apr 03 21:41:14 <fortnight> Cool! I saw your listing and I wanted to ask a couple of questions.
Apr 03 21:41:24 <jkridner> fortnight: the inner shebang is a startup script that gets written by the installer script.
Apr 03 21:41:31 <fortnight> Oh.
Apr 03 21:42:17 <jkridner> are you silver2row?
Apr 03 21:42:26 <fortnight> Yes.
Apr 03 21:42:52 <fortnight> I see line 24 as a cmd needs sudo. Should this be changed in the script?
Apr 03 21:44:20 <fortnight> Please do not forget I am a new user to the BBBlue. I have been delving in the BBB and variations for some time now.
Apr 03 21:44:20 <jkridner> I just updated.
Apr 03 21:44:24 <fortnight> Cool!
Apr 03 21:44:34 <fortnight> Should I check now?
Apr 03 21:45:28 <jkridner> well, if you've already run some stuff on your board, it'd probably not work to try to run the whole script again.
Apr 03 21:45:45 <jkridner> well, I guess nothing in there wouldn't run again.
Apr 03 21:46:15 <fortnight> Oh.
Apr 03 21:47:18 <fortnight> I can set up everything again. At first, the line 13 was not able to be used as a cmd b/c the rc.local was not listed in my directories.
Apr 03 21:47:23 <jkridner> fortnight: did you see https://beagleboard.org/p/jkridner/beaglebone-blue-220mm-quadcopter-9801d8 ?
Apr 03 21:47:37 <fortnight> No sir. Let me go and check it out.
Apr 03 21:47:55 <fortnight> I saw it. More!
Apr 03 21:48:08 <fortnight> Cool...I will test it and return service.
Apr 03 21:48:55 <fortnight> I set up line 23 and then I was able to run line 13 successfully.
Apr 03 21:49:06 <fortnight> Is this an issue?
Apr 03 21:50:17 <jkridner> oh!
Apr 03 21:50:21 <fortnight> Yes?
Apr 03 21:50:28 <jkridner> 23 should come *after* 13.
Apr 03 21:51:02 <jkridner> 13 is moving the existing /etc/rc.local to save it off.
Apr 03 21:51:17 <jkridner> 14-22 creates the new /etc/rc.local
Apr 03 21:51:27 <jkridner> 23 makes /etc/rc.local exectuable.
Apr 03 21:51:27 <fortnight> Oh. I understand but the rc.local was not listed in /etc until line 23 was run. Aw!
Apr 03 21:51:29 <fortnight> Okay.
Apr 03 21:51:58 <fortnight> So, the script runs the last shebang and lower script first?
Apr 03 21:52:37 <jkridner> The line 1 shebang is for the ardupilot_setup.sh script...
Apr 03 21:52:50 <fortnight> Okay.
Apr 03 21:53:02 <jkridner> the shebang on line 15 is part of what gets written by ardupilot_setup.sh into /etc/rc.local
Apr 03 21:53:33 <jkridner> you could just write lines 15-21 into /etc/rc.local, but that is what lines 14-22 *do*.
Apr 03 21:53:41 <fortnight> So, one file and the script does its job. Hmm. That actually sounds very nice.
Apr 03 21:53:47 <jkridner> line 23 makes it executable.
Apr 03 21:53:58 <jkridner> upon every reboot, /etc/rc.local will run.
Apr 03 21:54:04 <fortnight> So, I would just need to set up a service. Oh!
Apr 03 21:54:18 <fortnight> no service. Cool!
Apr 03 21:54:37 <jkridner> fortnight: a service file would be better... this is a bit lazy.
Apr 03 21:54:46 <fortnight> Okay. Done.
Apr 03 21:55:09 <jkridner> this is all assuming a bit of an old image and haven't tested with the latest. :-(
Apr 03 21:55:09 <fortnight> Sir, does mission Planner peoples have any idea that you made this work?
Apr 03 21:55:21 <fortnight> Aw...that is okay. I can test it out.
Apr 03 21:55:36 <jkridner> dunno.  some ArduPilot developers know.
Apr 03 21:55:40 * jkridner must go
Apr 03 21:55:44 <fortnight> Oh. Dang it!
Apr 03 21:55:49 <jkridner> back later tonight.
Apr 03 21:55:50 <fortnight> Okay sir. Later for now.
Apr 03 23:15:58 <FL4SHK> zmatt:  so I tried to do git checkout 4.14.30-bone14 -- patches/defconfig
Apr 03 23:16:35 <FL4SHK> The exact command you had put into the logs
Apr 03 23:16:41 <FL4SHK> didn't seem to work
Apr 03 23:17:38 <FL4SHK> will try the cherrypick thing I think
Apr 03 23:23:25 <zmatt> hmm, the tag was missing or something?
Apr 03 23:24:58 <zmatt> the tags /are/ missing, ho hum
Apr 03 23:28:12 <FL4SHK> Not seeing 4.14.30
Apr 03 23:28:21 <zmatt> fixed it
Apr 03 23:28:30 <FL4SHK> should I do a git pull then
Apr 03 23:28:34 <zmatt> now the tag does exist ( https://github.com/dutchanddutch/bb-kernel/commits/4.14.30-bone14 )
Apr 03 23:28:55 <FL4SHK> oh
Apr 03 23:28:55 <zmatt> yeah, though cherry-picking the sgx commit onto rcn's branch might be a better idea anyway
Apr 03 23:29:03 <FL4SHK> Oh, then I'll just do that.
Apr 03 23:31:01 <zmatt> unless you have specific use for the other patches I did
Apr 03 23:32:19 <FL4SHK> Probably not.
Apr 03 23:32:20 <zmatt> (like the fast link up patch)
Apr 03 23:32:25 <FL4SHK> Fast link up?
Apr 03 23:33:56 <zmatt> yeah, if you look at ethernet link you find it goes up and down multiple times because the link comes up by itself but then the ethernet phy gets reset by u-boot and again by the kernel
Apr 03 23:34:23 <FL4SHK> Is there any way to make it not flash so many lights
Apr 03 23:34:45 <FL4SHK> I've got it covered with a pair of shorts right now because I didn't like seeing the blue lights so much
Apr 03 23:34:49 <zmatt> at some point during boot optimization, that actually became a limiting factor for time until host is reachable, so I created a patch that suppresses phy reset when it looks like it's already okay
Apr 03 23:35:00 <zmatt> the blue lights are fully configurable
Apr 03 23:35:05 <FL4SHK> They can be turned off?
Apr 03 23:35:25 <zmatt> sure,  for i in /sys/class/leds/*/trigger; do echo none >$i; done
Apr 03 23:35:41 <zmatt> the defaults are configured in DT
Apr 03 23:36:08 <FL4SHK> ...well I see green ones
Apr 03 23:36:36 <zmatt> they're called green in sysfs for historical reasons
Apr 03 23:36:40 <FL4SHK> Ah.
Apr 03 23:36:55 <zmatt> they were green on the beaglebone white (the original beaglebone)
Apr 03 23:37:07 <zmatt> and people of course ended up hardcoding those names in stuff
Apr 03 23:37:41 <zmatt> so for backwards compat the names never changed :)
Apr 03 23:37:47 <zmatt> even though the led color did
Apr 03 23:37:50 <FL4SHK> oh lol
Apr 03 23:38:07 <FL4SHK> Yeah that's much better.
Apr 03 23:38:08 <zmatt> the power led can theoretically be turned off too
Apr 03 23:38:18 <FL4SHK> I'm fine with that one staying on.
Apr 03 23:38:21 <FL4SHK> on
Apr 03 23:39:13 <FL4SHK> is the git cherry-pick going to work with the RCN bb-kernel?
Apr 03 23:39:55 <zmatt> probably.  maybe minor manual fixup needed in the top-level patch.sh
Apr 03 23:40:18 <FL4SHK> Which bb-kernel.git do I need?  Both?
Apr 03 23:42:18 <zmatt> you can do it either way: if you clone my repo, you can do something like   git reset --hard 4.14.30-bone14 && git cherry-pick 2133fc92
Apr 03 23:42:32 <zmatt> ah, it does conflict in patch.sh, lemme see
Apr 03 23:42:46 <zmatt> yeah, easy to resolve
Apr 03 23:44:35 <zmatt> actually hold on
Apr 03 23:47:05 <zmatt> I figured moving the patch to the right line in patch.sh would help, but it actually doesn't make much difference
Apr 03 23:47:24 <FL4SHK> difference?
Apr 03 23:47:58 <zmatt> yeah I was hoping that it wouldn't get a conflict anymore on cherry-pick, but it still does.  although it's now even easier to resolve, so I pushed it anyway
Apr 03 23:48:46 <zmatt> (commit is now c6f93b75dab49)
Apr 03 23:49:02 <zmatt> wait I can rebase it down before all the other patches
Apr 03 23:49:06 <zmatt> then the problem is solved
Apr 03 23:49:29 <FL4SHK> I wish I knew git that well.
Apr 03 23:49:33 <FL4SHK> I don't know how to rebase though.
Apr 03 23:52:47 <FL4SHK> Let me know when the thing is pushed so I can pull.
Apr 03 23:53:16 <ds2> hey zmatt, would you happen to have any insight on what a DMA transaction error would refer to?
Apr 03 23:54:26 <zmatt> FL4SHK: I've just pushed... beware that I've done rebasing so you can't pull unless you first move back to a common revision, e.g.:   git reset --hard 4.14.30-bone14
Apr 03 23:54:32 <zmatt> ds2: what do you mean?
Apr 03 23:54:42 <FL4SHK> I've done no edits
Apr 03 23:55:25 <zmatt> FL4SHK: edits aren't the issue, if you have the previous version of my branch checked out and then try to merge the new version of my branch (which has the same patches but in a different order), hilarity ensues
Apr 03 23:55:28 <windsurf_> why is it that after resizing my SD card partition with fdisk I see this in fdisk:   /dev/mmcblk0p1       8192 15564799 15556608  7.4G 83 Linux       (which is expected for my 8GB card) but when I do     df -h     I get,   /dev/mmcblk0p1  3.3G  1.6G  1.5G  53% /
Apr 03 23:55:38 <FL4SHK> Oh then I'll just re-clone.
Apr 03 23:55:41 <FL4SHK> Will that work?
Apr 03 23:55:52 <ds2> zmatt: trying to figure out what is causing the DMA engine to report a DMA transaction error in the CCR register...
Apr 03 23:55:58 <windsurf_> the latter appears to report the original 4GB, which is I believe the size of the distro I flashed to the disk
Apr 03 23:56:03 <zmatt> FL4SHK: yes of course, though it's not necessary.  you can use the reset command I just gave
Apr 03 23:56:07 <zmatt> and then pull
Apr 03 23:56:22 <zmatt> windsurf_: resize2fs /dev/mmcblk0p1
Apr 03 23:56:32 <zmatt> windsurf_: (you're allowed to do it on a mounted filesystem)
Apr 03 23:57:09 <windsurf_> so I tried resize2fs /dev/mmcblk0p1 on its own and it didn't seem to have an effect but it did just seem to work after the fdisk stuff (so I need both)
Apr 03 23:57:10 <FL4SHK> so do I just need to do ./build_kernel.sh now?
Apr 03 23:57:39 <zmatt> FL4SHK: do you have a system.sh ?
Apr 03 23:57:55 <FL4SHK> I do not
Apr 03 23:58:16 <zmatt> windsurf_: resize2fs (with no arguments other than the partition) expands the filesystem to fit the partition
Apr 03 23:58:56 <zmatt> windsurf_: so yes you first need to expand/recreate the partition to have max size, and then use resize2fs to expand the filesystem that resides in the partition
Apr 03 23:59:25 <zmatt> ds2: in general, anything that would result in a bus error or L3 interconnect error if the cpu did it
Apr 03 23:59:36 <zmatt> ds2: speaking of, the L3 interconnect errors logs may have recorded more details
Apr 04 00:00:07 <zmatt> hmm, how far did I ever get with userspace tools to examine those...
Apr 04 00:00:55 <windsurf_> zmatt i see the distinction, thanks
Apr 04 00:01:06 <zmatt> FL4SHK: create it based on system.sh.sample
Apr 04 00:01:09 <FL4SHK> So do I need to do the cherry-pick thing with the new commit?
Apr 04 00:01:11 <FL4SHK> Alright
Apr 04 00:01:50 <FL4SHK> I guess I'd better modify the ARCH
Apr 04 00:01:53 <zmatt> FL4SHK: in fact the sgx commit is now the first one on top of rcn's
Apr 04 00:01:57 <zmatt> what?
Apr 04 00:02:09 <FL4SHK> It's "uname -m" in the sample
Apr 04 00:02:09 <zmatt> no, leave that
Apr 04 00:02:11 <zmatt> yes
Apr 04 00:02:11 <FL4SHK> oh okay
Apr 04 00:02:26 <FL4SHK> But wouldn't that set it as my host's thing?
Apr 04 00:02:35 <FL4SHK> ...or should I be compiling the kernel on the device itself?
Apr 04 00:02:51 <zmatt> it's not the ARCH it's passing to the kernel evidently, I don't know what it's used for either
Apr 04 00:02:56 <FL4SHK> alright.
Apr 04 00:02:59 <zmatt> just as CC isn't the path to a C compiler
Apr 04 00:03:05 <FL4SHK> ah, right.
Apr 04 00:03:16 <zmatt> enable AUTO_BUILD=1 to skip the kernel config menu
Apr 04 00:03:22 <zmatt> if you don't care about tweaking the kernel config
Apr 04 00:03:34 <FL4SHK> Do I still need to do the cherry-pick?
Apr 04 00:04:07 <FL4SHK> sorry my git-foo might be a bit weak.
Apr 04 00:04:09 <zmatt> the sgx commit is now the first one on top of rcn's branch, so you can just go directly to that one with git reset --hard e677b1b869f2
Apr 04 00:04:39 <zmatt> in general I've tried to move potentially useful patches all the way down
Apr 04 00:05:06 <FL4SHK> "HEAD is now at e677b1b8 support new ti sgx drivers"
Apr 04 00:07:28 <FL4SHK> Well I set CORES=4 and AUTO_BUILD=1 in system.sh
Apr 04 00:07:38 <zmatt> I think it auto-detects CORES
Apr 04 00:07:45 <FL4SHK> Ah
Apr 04 00:08:03 <ds2> zmatt: so SIGSEGV for the DMA engine?
Apr 04 00:08:05 <zmatt> I've only set CC to use an already installed toolchain, LINUX_DIR to one I already had, and AUTO_BUILD
Apr 04 00:08:26 <FL4SHK> at this point, ./build_kernel.sh?
Apr 04 00:08:35 <zmatt> ds2: SIGBUS for the DMA engine. (SEGV = mmu violation)
Apr 04 00:08:38 <zmatt> FL4SHK: yep
Apr 04 00:08:46 <FL4SHK> excellent.
Apr 04 00:09:42 <zmatt> ds2: if the dma engine isn't too busy, you may be able to fish details about the failed transfer from the transfer controller's registers
Apr 04 00:09:59 <zmatt> actually, I think it keeps info about the last fault?
Apr 04 00:10:07 <zmatt> or wait, wait
Apr 04 00:10:14 <zmatt> maybe I'm confused about which register CCR is
Apr 04 00:10:40 <FL4SHK> zmatt:  so after the kernel builds, I can just copy it on over to my BBB?
Apr 04 00:10:41 <zmatt> in my own headers I renamed them to be a lot more descriptive :P
Apr 04 00:11:01 <FL4SHK> There was more wasn't there?
Apr 04 00:11:31 <zmatt> FL4SHK: there was a lot more
Apr 04 00:11:35 <FL4SHK> oooh, alright
Apr 04 00:11:42 <FL4SHK> Guess I'd better let the kennel build then.
Apr 04 00:11:49 <FL4SHK> Thanks for helping me through that.
Apr 04 00:11:50 <zmatt> but let's first see this kernel works for you on arch
Apr 04 00:12:09 <FL4SHK> Oh, that makes sense too.
Apr 04 00:12:15 <FL4SHK> How do I install the kernel?
Apr 04 00:12:16 <zmatt> after that comes building the sgx kernel module in https://github.com/mvduin/omap5-sgx-ddk-linux
Apr 04 00:13:01 <zmatt> (by doing something loosely based on build.sh, but with the hardcoded paths fixed to match your setup and without building a debian package for it)
Apr 04 00:14:19 <zmatt> ds2: I don't see any CCR register
Apr 04 00:14:23 <zmatt> ds2: CCERR maybe?
Apr 04 00:14:44 <zmatt> or something else?
Apr 04 00:20:19 <FL4SHK> Are you sure CORES is auto detected
Apr 04 00:20:48 <zmatt> if [ ! "${CORES}" ] ; then  CORES=$(getconf _NPROCESSORS_ONLN);  fi
Apr 04 00:21:04 <FL4SHK> cool
Apr 04 00:22:33 <zmatt> ds2: if you meant CCERR then I'd be really intrigued
Apr 04 00:23:45 * zmatt pokes ds2 
Apr 04 00:34:32 <FL4SHK> zmatt:  it has built.
Apr 04 00:34:41 <FL4SHK> I will probably try this tomorrow.
Apr 04 01:04:19 <ds2> zmatt: buried in debugging... figured out caused it.. one of the addresses is 0 :/
Apr 04 01:04:58 <zmatt> cool, so proper l3 error reporting would have revealed that
Apr 04 01:04:59 <FL4SHK> oh boy a null pointer
Apr 04 01:05:12 <zmatt> FL4SHK: 0 is a valid address on the L3 interconnect actually
Apr 04 01:05:14 <FL4SHK> oh okay
Apr 04 01:05:18 <zmatt> belongs to GPMC
Apr 04 01:05:22 <FL4SHK> ...I would hope so honestly
Apr 04 01:06:21 <zmatt> I suspect sane people would never setup a memory range there though
Apr 04 01:06:40 <zmatt> (especially since the cortex-a8 would not be able to access it)
Apr 04 01:18:13 <fortnight> boy 'o boy!
Apr 04 01:19:15 <fortnight> CNC fans?
Apr 04 01:20:03 <fortnight> That place had a RepliCape. I am going to try it out. Do not fret, I will report.
Apr 04 01:21:29 <fortnight> Has anyone tried to set-up Mission Planner w/ the BBBlue?
Apr 04 01:49:33 <fortnight> Forget Mission Planner. I asked their forum since it is more related to set-up stuff on their end.
Apr 04 02:32:28 <cisco76254R> hi all
Apr 04 02:33:22 <fortnight> https://pastebin.com/B4Nm18t1 is my printed version of the idea that my system does not have /etc/rc.local by the time the command is given to move the file.
Apr 04 02:33:26 <fortnight> Please review it.
Apr 04 02:33:49 <fortnight> Do I need to make a file first called rc.local or should I manage it another way?
Apr 04 02:37:35 <fortnight> Oh and that .sh file is from: https://gist.github.com/jadonk/6080ca92d6e225eb89d33ad7744e1775#file-ardupilot_setup-sh.
Apr 04 02:37:36 <fortnight> ...
Apr 04 02:38:03 <fortnight> If you have ideas, let a brother know. Thank you, again.
Apr 04 02:43:54 <fortnight> ...
Apr 04 02:44:53 <fortnight> Scratch that. I just checked and the file is there in /etc and so is /etc/rc.local.bak.xxxxx.
**** ENDING LOGGING AT Wed Apr 04 03:00:01 2018