**** BEGIN LOGGING AT Fri Sep 14 03:00:12 2018
Sep 14 04:10:49 <set_> I got m2 to turn on!
Sep 14 04:11:07 <set_> I went for m3 but got m2! Still kosher.
Sep 14 04:12:08 <set_> m1 is a go!
Sep 14 04:12:26 <set_> Now, I need to figure out how to turn these things off!
Sep 14 04:17:21 <set_> Yea boy! Off!
Sep 14 04:18:58 <set_> @jkridner: Sir, I got your MotorCape. This thing is more interesting than I thought, esp. w/ the Adafruit_BBIO/Adafruit_GPIO stuff.
Sep 14 04:19:24 <jkridner> cool
Sep 14 04:19:28 <jkridner> interesting enough to put something up on bbb.io/p talking about it?
Sep 14 04:19:28 <set_> I have turned on and off the LEDs for Motor1 and Motor4.
Sep 14 04:19:44 <set_> What do you think?
Sep 14 04:19:55 <jkridner> well, have you managed to set the PWMs?
Sep 14 04:19:59 <set_> Yep.
Sep 14 04:20:04 <jkridner> I've got a few code snippets from the command-line.
Sep 14 04:20:13 <set_> It was Motor1 and Motor2, sorry.
Sep 14 04:20:34 <set_> I saw one about bonescript and node.js.
Sep 14 04:20:39 <set_> for a stepper.
Sep 14 04:20:41 <jkridner> a bit long-winded, but: https://github.com/jadonk/beagle-tester/blob/master/beagle-tester.c#L3934
Sep 14 04:20:52 <set_> Okay.
Sep 14 04:20:56 <set_> I can check it out.
Sep 14 04:21:03 <jkridner> could do it with BoneScript too.
Sep 14 04:21:35 <set_> So, PWM handles the LEDs. I will have to read more about I2C.
Sep 14 04:21:49 <jkridner> i2c?
Sep 14 04:21:56 <jkridner> for the Motor Cape?
Sep 14 04:22:00 <set_> Yea!
Sep 14 04:22:05 <jkridner> why?
Sep 14 04:22:17 <set_> I think. I do not know why! I wantedd to try everything.
Sep 14 04:22:53 <zmatt> because set_ is usually confused :P
Sep 14 04:22:59 <set_> Yes. That is all.
Sep 14 04:23:04 <jkridner> :-)
Sep 14 04:23:13 <set_> I am very unfamiliar w/ most things I am involved in.
Sep 14 04:23:25 <set_> But...I can say this much! I still try.
Sep 14 04:23:43 <set_> What are the chips on these things?
Sep 14 04:24:05 <set_> I saw on the schematic, they say Thermal Pad.
Sep 14 04:24:46 <set_> So, I am guessing I should use UART?
Sep 14 04:25:16 <zmatt> ???
Sep 14 04:25:30 <set_> I really do not get it yet!
Sep 14 04:25:35 <zmatt> that much is evident
Sep 14 04:26:16 <jkridner> the PWM's set the drive strength, a GPIO sets the direction.
Sep 14 04:27:02 <set_> Oh!
Sep 14 04:27:11 <zmatt> also a "thermal pad" is a large solder pad that allows an IC to use the pcb as a heat sink
Sep 14 04:27:19 <set_> Oh!
Sep 14 04:27:38 <set_> I am about to run my funny software and see what happens!
Sep 14 04:27:43 <set_> Would you like to see it?
Sep 14 04:30:36 <zmatt> *like* ? not particularly, but if you want me to look at it I probably will :P
Sep 14 04:30:40 <jkridner> I'll try to get a README.md file setup with the motor driver tomorroe.
Sep 14 04:30:49 <set_> Okay.
Sep 14 04:30:58 <set_> I will keep trying to make things go.
Sep 14 04:31:40 <set_> zmatt: Do not worry. The LED does not control the motor. No biggie!
Sep 14 04:31:44 <set_> Ha!
Sep 14 04:34:39 <set_> Okay. I got the darn LED running for 15 seconds w/ "100!" printing out while the LED is lit.
Sep 14 04:35:03 <set_> Sorry. It is 100! x 15 until the system ends.
Sep 14 04:35:51 <set_> So, I2C is too slow for this device?
Sep 14 04:42:57 <zmatt> for what? what do you mean?
Sep 14 04:43:37 <set_> Forget it. I am just testing different software to run a motor here.
Sep 14 04:43:42 <set_> Nothing important.
Sep 14 04:43:57 <set_> Well, it may be important.
Sep 14 04:44:00 <set_> But, I doubt it.
Sep 14 04:44:13 <zmatt> I hope you're not trying to use the adafruit motor bridge cape stuff since that's not remotely compatible
Sep 14 04:44:37 <set_> No Motor Bridge Stuff. But yep. I tried.
Sep 14 04:44:40 <set_> It works w/ the LED.
Sep 14 04:44:44 <set_> sorry. LEDs.
Sep 14 04:45:07 <set_> I could not figure out the Motor3 and Motor4 for the LED usage.
Sep 14 04:45:31 <set_> Oh.
Sep 14 04:50:07 <CoffeeBreakfast> I followed the guide from www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black, and I'm getting ** Invalid partition 2 **, so, unable to boot from SD
Sep 14 04:50:45 <set_> What pin config should I use for a GPIO pin for the MotorCape?
Sep 14 04:50:51 <CoffeeBreakfast> I followed the guide from www.digikey.com/eewiki/display/linuxonarm/BeagleBone+Black, and I'm getting ** Invalid partition 2 **, so, unable to boot from SD
Sep 14 04:51:00 <CoffeeBreakfast> Sorry for the doble
Sep 14 04:52:07 <zmatt> CoffeeBreakfast: uhh, what is trying to accesss partition 2 and why? normally there's only one partition
Sep 14 04:52:44 <zmatt> do you have some ancient system on eMMC ?
Sep 14 04:53:57 <CoffeeBreakfast> nope, 4.14-ti image
Sep 14 04:54:32 <CoffeeBreakfast> and fdisk tells me that there is only 1 partition
Sep 14 04:54:38 <zmatt> can you pastebin the complete output from u-boot ?
Sep 14 04:55:26 <zmatt> are you powering on with or without the S2 button held down?
Sep 14 04:55:50 <CoffeeBreakfast> held down
Sep 14 04:56:10 <zmatt> okay so the u-boot on eMMC isn't relevant anyhow, so it's a problem with the u-boot you built
Sep 14 04:56:11 <CoffeeBreakfast> https://pastebin.com/afzvuAqM
Sep 14 04:56:32 <zmatt> yeah that output looks really strange
Sep 14 04:56:51 <zmatt> uhh wait
Sep 14 04:57:04 <zmatt> it's actually booting a kernel
Sep 14 04:58:17 <CoffeeBreakfast> yes, but not the one I put on the SD card
Sep 14 04:58:34 <zmatt> yeah I see that now
Sep 14 04:59:39 <zmatt> the error you quoted isn't a relevant error though
Sep 14 04:59:50 <zmatt> it's just trying all partitions sequentially
Sep 14 05:00:04 <zmatt> the issue is that it doesn't seem to regard partition 1 of the sd card as being bootable
Sep 14 05:01:03 <zmatt> it loaded /boot/uEnv.txt from it and then just seemed to give up, try the non-existent partitions 2..7 and finally booted from eMMC as fallback
Sep 14 05:01:33 <CoffeeBreakfast> The only error I found following that guide, was once, when doing sfdisk, and getting "Failed to add partition...", then restart from clearing the partition table, an redo the rest, no issues then
Sep 14 05:01:59 <zmatt> check whether your /boot/uEnv.txt sets the uname_r variable and whether /boot/vmlinuz-${uname_r} exists
Sep 14 05:02:31 <CoffeeBreakfast> okay
Sep 14 05:02:59 <zmatt> it should exist as a result of the "Copy kernel image" step on the wiki page
Sep 14 05:05:26 <CoffeeBreakfast> uEnv.txt: uname_r=4.18.7-bone7
Sep 14 05:05:42 <CoffeeBreakfast> vmlinuz-4.18.7-bone7 exist
Sep 14 05:06:14 <zmatt> then I'm not sure what it wants, you'd need to check u-boot's boot scripts
Sep 14 05:07:11 <CoffeeBreakfast> where are they?
Sep 14 05:07:31 <zmatt> in u-boot's source code, or you dump them with the printenv command
Sep 14 05:11:27 <set_> I am currently have trouble w/ config-pin on the BBBW and w/ the MotorCape.
Sep 14 05:12:03 <zmatt> if it's an actual cape then its pins should be set up automatically and using config-pin on those pins is neither necessary nor possible
Sep 14 05:12:04 <set_> Oh forget it. I just thought I could use p9.14 as a gpio.
Sep 14 05:12:23 <set_> Oh.
Sep 14 05:12:35 <zmatt> if it's a new-ish cape, do make sure your overlays package is uptodate
Sep 14 05:12:44 <set_> Aw!
Sep 14 05:14:06 <CoffeeBreakfast> I'm on u-boot prompt
Sep 14 05:17:25 <CoffeeBreakfast> printenv -> huge
Sep 14 05:17:36 <zmatt> yep, bon apetit!
Sep 14 05:18:08 <CoffeeBreakfast> any other command?
Sep 14 05:18:21 <zmatt> what, the output of printenv wasn't enough for you? :)
Sep 14 05:21:15 <CoffeeBreakfast> mmm there is mmc commands
Sep 14 05:54:35 <CoffeeBreakfast> just for curiosity's sake: how $board_name is defined? how u-boot can know the board, to set the dtb filename?
Sep 14 05:56:42 <CoffeeBreakfast> (distro_bootcmd is where the problems start)
Sep 14 06:02:54 <zmatt> u-boot identifies the board based on the contents of the board id eeprom
Sep 14 06:03:37 <zmatt> keep in mind that your u-boot is able to boot the linux system on eMMC successfully, so the problem is almost certainly with your rootfs, not with u-boot
Sep 14 06:07:32 <CoffeeBreakfast> okay
Sep 14 06:27:11 <CoffeeBreakfast> U-Boot is really interesting... eMMC: bbb-uEnv.txt, ID.txt, nfs-uEnv.txt are on /
Sep 14 06:27:21 <CoffeeBreakfast> SD: none of those are in /
Sep 14 06:27:34 <zmatt> none of those are relevant
Sep 14 06:33:46 <zmatt> based on a quick inspection of u-boot's boot script it really does look like the output from u-boot is only consistent with the kernel being missing
Sep 14 06:34:07 <zmatt> the last line shown from the attempt to boot from sd card is "Running uname_boot ...
Sep 14 06:35:09 <zmatt> and the first thing uname_boot does is: https://pastebin.com/D10K6hmi
Sep 14 06:35:20 <zmatt> that "loading" line is never echoed
Sep 14 06:35:43 <zmatt> hence, the test for existence of the kernel failed
Sep 14 06:54:44 <CoffeeBreakfast> uEnv.txt is there, but if fails a test like : if test -e ${devtype} ${bootpart} /uEnv.txt; then echo OK; fi
Sep 14 06:54:54 <CoffeeBreakfast> but it fails*
Sep 14 06:55:50 <zmatt> no it loads /boot/uEnv.txt just fine: Loaded environment from /boot/uEnv.txt
Sep 14 06:56:19 <zmatt> /uEnv.txt is some backwards compat thing, you can ignore that
Sep 14 06:56:50 <CoffeeBreakfast> oh
Sep 14 06:59:03 <CoffeeBreakfast> I wasn't seeing that "/boot" part lol
Sep 14 06:59:53 <zmatt> it found /boot/uEnv.txt, loaded it, verified uname_r was set, and then called the uname_boot function
Sep 14 07:00:33 <zmatt> the very first thing it does is verify the existence of /boot/vmlinuz-${uname_r} and then it will echo a "loading" line for that and load it
Sep 14 07:00:38 <zmatt> that line never appears in your log
Sep 14 07:00:44 <zmatt> so check for typos
Sep 14 07:00:56 <zmatt> in either the value of uname_r, or the filename of the kernel
Sep 14 07:04:15 <CoffeeBreakfast> Dave Jones usually says: "I hope your project doesn't work!", and I'm learning a lot
Sep 14 07:33:33 <CoffeeBreakfast> O.o run loadimage -> File not found /boot/vmlinuz-4.18.7-bone7 ...then..
Sep 14 07:35:30 <CoffeeBreakfast> load ${devtype} ${bootpart} ${bootdir}/vmlinuz-4.18.7-bone7 -> 8966656 bytes read...
Sep 14 07:36:19 <CoffeeBreakfast> is there an invisible character I can't see?
Sep 14 07:38:14 <CoffeeBreakfast> \r
Sep 14 07:44:55 <CoffeeBreakfast> uEnv.txt -> cat -A -> uname_r=4.18.7-bone7^M$
Sep 14 07:45:38 <zmatt> lol, that sucks
Sep 14 07:47:00 <CoffeeBreakfast> should be ...bone7$ right? is taking \r as part of the uname I guess
Sep 14 07:48:17 <zmatt> I can imagine that's what's happening yes
Sep 14 07:58:28 <CoffeeBreakfast> guess what...
Sep 14 07:58:38 <CoffeeBreakfast> it works
Sep 14 07:58:54 <zmatt> lesson learned: don't put DOS linebreaks in config files :)
Sep 14 08:01:10 <CoffeeBreakfast> thanks for the patience zmatt
Sep 14 10:08:38 <set_> How can I set my GPIO channel as an output?
Sep 14 10:08:52 <set_> I am using the MotorCape and I am receiving errors of this kind.
Sep 14 10:10:08 <set_> Here is my error: P9_14 pinmux file not found!
Sep 14 10:31:38 <set_> So, are the schematics or MotorCape mislabeled?
Sep 14 10:56:18 <set_> Well, by any means, this will be a surprise.
Sep 14 10:56:19 <set_> !
Sep 14 11:09:56 <set_> Just an update...I updated my bootloader to 2018-03-xx.
Sep 14 12:19:55 <zmatt> set_: neither, the problem is you have trouble reading
Sep 14 12:20:05 <zmatt> 07:12 < zmatt> if it's an actual cape then its pins should be set up automatically and using config-pin on those pins is neither necessary nor possible
Sep 14 12:20:51 <zmatt> hence, getting that error is the expected result
Sep 14 12:22:01 <zmatt> (when attempting to reconfigure the pin)
Sep 14 14:13:42 <set_> Oh.
Sep 14 14:13:44 <set_> Thank you.
Sep 14 14:13:48 <set_> BBL!
Sep 14 14:13:55 <set_> work day in 'da house.
Sep 14 14:27:26 <konsgn> is there a good reference to making a custom product out of the BBBW? I got the eagle file, and am ready to layout, but I'm not sure how far I'll need to go in the software to customize it to the layout. Is there an guide or references out there?
Sep 14 15:17:12 <KotH> well, you will need to access the additional periphery you are using
Sep 14 15:17:16 <KotH> and this needs initialization
Sep 14 15:18:14 <KotH> so, probably at least a new DT, possibly a different kernel and your application
Sep 14 15:33:04 <ayjay_t> WELP
Sep 14 15:33:31 <ayjay_t> 5V on the ADC is TOO DAMN HIGH
Sep 14 15:34:31 <zmatt> even 2V would be too damn high
Sep 14 15:36:50 <zmatt> konsgn: like KotH said you'll need to make a custom dts.  you may also want to consider programming a different board id into the eeprom and add the appropriate code to u-boot to recognize it and pick the correct dts
Sep 14 15:37:18 <zmatt> *correct dtb
Sep 14 15:37:29 <konsgn> so dts is a singular thing, and the overlays are additional ones that are meant more for testing?
Sep 14 15:37:32 <zmatt> (alternatively you can just explicitly override the dtb selection in /boot/uEnv.txt )
Sep 14 15:38:41 <zmatt> overlays are used to modularize things, since the bbb can be used with a variety of hardware attached
Sep 14 15:39:16 <zmatt> if your custom pcb is sufficiently similar to a BBB with a cape, you could also use an overlay to declare your extra hardware
Sep 14 15:40:10 <konsgn> okay, so the overlay is not something I necessarily need, i just need to compile my own DT describing hardware attached and that loads appropriate drivers?
Sep 14 15:41:36 <zmatt> it's basically either-or.  overlays are basically just patches applied to the DT by u-boot
Sep 14 15:41:47 <konsgn> cool, thank you!
Sep 14 15:41:56 <zmatt> they make it relatively easy to add or remove chunks of functionality
Sep 14 15:42:49 <zmatt> at the cost of making it somewhat harder to debug dt issues (since dtc can do almost no error-checking when compiling overlays)
Sep 14 15:42:57 <konsgn> indeed i have noticed that config-pin capable of switching out pin functionalities
Sep 14 15:43:29 <zmatt> that's not really related to overlays
Sep 14 15:44:14 <zmatt> overlays are applied at boot time by u-boot, before the kernel loads, while config-pin is runtime selection of pinmux
Sep 14 15:45:06 <zmatt> runtime selection is convenient for experimenting, but typically not what you'd want in a final product
Sep 14 15:45:57 <ayjay_t> is it still prone to kernel panics/random failure?
Sep 14 15:46:23 <zmatt> no, that was runtime-loading of overlays, which has been deprecated and is no longer used by default
Sep 14 15:46:37 <ayjay_t> i figured the whole dt system was like taht
Sep 14 15:46:42 <ayjay_t> but you're right
Sep 14 15:46:47 <zmatt> its bugginess is part of why overlays were deprecated
Sep 14 15:46:56 <ayjay_t> so overlays were deprecated eh
Sep 14 15:47:04 <ayjay_t> all overlays, not just runtime
Sep 14 15:47:06 <zmatt> runtime-loading of overlays is
Sep 14 15:47:09 <ayjay_t> oh okay
Sep 14 15:47:10 <zmatt> sorry
Sep 14 15:47:14 <ayjay_t> so is there a replacement?
Sep 14 15:47:19 <ayjay_t> not that i'd need it
Sep 14 15:47:25 <zmatt> u-boot overlays are used by default now
Sep 14 15:47:36 <ayjay_t> i'll have to take a look at how that differs
Sep 14 15:47:41 <zmatt> i.e. the overlays are applied to the main dt by u-boot before the dt is passed to the kernel
Sep 14 15:47:49 <ayjay_t> OH
Sep 14 15:47:55 <ayjay_t> so no runtime subsitute with that method
Sep 14 15:48:08 <zmatt> correct
Sep 14 15:49:43 <zmatt> the bugginess of runtime overlays is because the kernel always assumed the dt was an immutable thing, and trying to find and fix things that break when the dt is no longer immutable turned out kinda hopeless
Sep 14 15:52:27 <ayjay_t> kind of a bummer
Sep 14 15:56:16 <zmatt> well you're basically expecting the kernel to react well to a spontaneously changing PCB
Sep 14 15:57:41 <konsgn> haha, fpga surrounds the processor
Sep 14 15:57:47 <KotH> and you can do ugly thing with DT...
Sep 14 15:57:57 * KotH once used the same pins for 3 different peripherals
Sep 14 15:58:17 <KotH> and i'm not proud of it
Sep 14 15:58:18 <zmatt> KotH: normally the kernel should refuse that
Sep 14 15:58:30 <zmatt> s/should/will/
Sep 14 15:58:32 <konsgn> yup, done that too, but only on a smaller processor, the esp8266. was a bitch to modify all the libraries
Sep 14 15:58:53 <KotH> zmatt: loading differen DT each time works.. but it's fucking ugly
Sep 14 15:58:54 <georgem> KotH: and other things... (like eat Hersheys)
Sep 14 15:59:06 <zmatt> KotH: it is
Sep 14 15:59:25 <zmatt> the cape-universal way is the alternative (use a pinmux helper device to switch pinmux at runtime)
Sep 14 15:59:47 <KotH> georgem: EWWWW!!!
Sep 14 16:01:29 <konsgn> is /boot/dtbs/4.14.49-ti-r54/am335x-pocketbeagle.dtb the default device tree? it says blob, dous that mean its only partial?
Sep 14 16:01:59 <zmatt> dtb is a compiled device tree
Sep 14 16:02:13 <zmatt> that one for the pocketbeagle specifically
Sep 14 16:03:01 <konsgn> is there a way to see which device tree/ overlays ar currently used?
Sep 14 16:03:32 <georgem> you can go view the current devicetree but I don't think it keeps track of where it came from
Sep 14 16:05:53 <konsgn> okay cool, cat /sys/firmware/devicetree/base/model seems to have it
Sep 14 16:05:59 <georgem> yeah
Sep 14 16:06:17 <zmatt> no, you can't
Sep 14 16:06:25 <zmatt> easiest way is by checking the output from u-boot via the serial console
Sep 14 16:06:57 <konsgn> and thats to see where it's loaded from, correct?
Sep 14 16:20:47 <konsgn> Thanks a lot @zmatt, gtg
Sep 14 18:51:02 <CoffeeBreakfast> /sys/kernel/debug/pinctrl/pinctrl-devices: what kind of info is telling that file?
Sep 14 18:56:31 <zmatt> hmm, that name doesn't ring a bell... I don't think I consult it in my show-pins utility
Sep 14 18:57:04 <zmatt> ah it just list all pinmux/pinctrl devices
Sep 14 18:57:16 <zmatt> or, device-types it more looks like
Sep 14 18:57:18 <zmatt> weird
Sep 14 18:58:43 <zmatt> no, it must be devices
Sep 14 19:00:43 <CoffeeBreakfast> I've been doing research, about the eCAP2 issue
Sep 14 19:00:53 <zmatt> "the eCAP2 issue" ?
Sep 14 19:00:56 <zmatt> oh right
Sep 14 19:01:09 <zmatt> your pins were mysteriously not getting muxed
Sep 14 19:01:20 <CoffeeBreakfast> yes
Sep 14 19:01:44 <CoffeeBreakfast> I tested in a pocketbeagle also
Sep 14 19:02:01 <zmatt> oh jesus, wth did I really screw up this badly
Sep 14 19:02:38 <CoffeeBreakfast> Could be hardcoded in some driver to not let mux some pins?
Sep 14 19:03:35 <zmatt> I just looked at that pwmss2.dtsi file again and noticed I never even reference the pinmux nodes
Sep 14 19:04:35 <zmatt> sorry for causing you to waste so much of your time
Sep 14 19:05:06 <zmatt> I should have looked at this file more carefully the last time (although I was a bit tired and/or distracted at the time I think)
Sep 14 19:05:51 <CoffeeBreakfast> zmatt: no worries, troubleshooting is a good way to learn
Sep 14 19:08:32 <zmatt> unrelated to that, I am a bit puzzled that that pinctrl-devices file in debugfs is showing a bogus name for the pinmux controller (at least on my system)
Sep 14 19:10:02 <CoffeeBreakfast> name [pinmux] [pinconf] \ pinctrl-single yes no \ 44e3e000.rtc no yes  (on my BBB)
Sep 14 19:10:08 <zmatt> exactly
Sep 14 19:10:24 <zmatt> the second one is a proper device name, the first one isn't
Sep 14 19:10:40 <zmatt> I've pushed a (hopefully) fixed version of pwmss2.dtsi
Sep 14 19:13:57 <CoffeeBreakfast> pinctrl-single is the device driver for the device at 44e10800 ?
Sep 14 19:14:47 <zmatt> yes, but the first column in that file is supposed to list the device name (44e10800.pinmux), not the driver name
Sep 14 19:15:38 <CoffeeBreakfast> ohh
Sep 14 19:21:48 <CoffeeBreakfast> pinctrl-names = "default"; pinctrl-0 = <&cap2_pins>; could you explain me those lines?
Sep 14 19:43:47 <zmatt> CoffeeBreakfast: the first is an array of pinmux state names for the device.  the second gives a list of pinmux nodes for pinmux state 0 (i.e. "default") of the device.  multiple pinmux nodes may be needed for a state in case more than one pinmux controller is involved (since the pinmux node is a child of the pinmux controller)
Sep 14 19:44:26 <zmatt> usually devices only have a "default" state, and maybe a "sleep" state (used during suspend-to-ram)
Sep 14 19:52:53 <CoffeeBreakfast> good
Sep 14 19:56:11 <sicelo> ok, this is crazy - https://www.youtube.com/watch?v=epGCQLdYmow
Sep 14 19:57:55 <CoffeeBreakfast> cute
Sep 14 19:58:11 <zmatt> yeah that's an oldie
Sep 14 20:00:11 <sicelo> it's really cute and funny. first time i see it
Sep 14 20:05:43 <sicelo> what are people doing with their beaglebones. any cool projects availabl somewhere besides hackster.ip?
Sep 14 20:05:47 <sicelo> *.io
Sep 14 20:07:12 <CoffeeBreakfast> it's alive!!!! 103 fast rx down 4 eCAP 2
Sep 14 20:08:25 <CoffeeBreakfast> I'm still learning the beaglebone... this is my first year on embedded linux
Sep 14 20:10:00 <sicelo> CoffeeBreakfast: \m/
Sep 14 20:10:55 <sicelo> what project you have in mind for it?
Sep 14 20:14:28 <CoffeeBreakfast> for me, my BBB is more like a swiss army knife
Sep 14 21:06:01 <set_> repitition at its finest!
Sep 14 21:06:19 <set_> Will you please tell me what I missed?
Sep 14 21:11:40 <set_> Scratch that idea. I have logs. I got the logs!
Sep 14 21:20:41 <thinkfat> looks like the logbots are still having a hard time
Sep 14 21:22:32 <thinkfat> beagleboard still has no logs and nslu2 has spotty coverage...
Sep 14 21:22:59 <thinkfat> zmatt: 48kHz bcs HDMI?
Sep 14 21:23:12 <thinkfat> zmatt: and everything else must be resampled?
Sep 14 21:43:25 <ayjay_t> bbb is the bbbest
Sep 14 21:43:34 <set_> Boy!
Sep 14 21:44:23 <set_> Are there any scripts for the Motor Cape yet? I have been trying but I am a well-known failure so far.
Sep 14 21:46:05 <set_> I see there is a doc-beaglebone-getting-started something or other. I will look at this item.
Sep 14 21:52:28 <ss> hi
Sep 14 21:52:36 <ss> anyone thr?
Sep 14 21:52:59 <Guest83009> hi'
Sep 14 21:53:07 <Guest83009> anybody th
Sep 14 21:53:10 <Guest83009> thr?
Sep 14 21:53:28 <Guest83009> hello
Sep 14 21:53:43 <set_> Hello Guest: What may be your query?
Sep 14 21:54:48 <Guest83009> can you give me any document of how to connect bbb through ehternet
Sep 14 21:55:04 <set_> Dang!
Sep 14 21:55:11 <Guest83009> and eith other sources like sd card, nand flash, nor flash
Sep 14 21:55:18 <set_> I just read something about that. Please hold.
Sep 14 21:55:28 <Guest83009> ok sure
Sep 14 21:55:38 <set_> Wait. It is now read only! Do you still want it?
Sep 14 21:55:46 <Guest83009> yes
Sep 14 21:55:56 <set_> Okay. Please hold.
Sep 14 21:56:00 <Guest83009> sure
Sep 14 21:57:31 <Guest83009> i need to know the process of configuration through NAND, NOR,ETHERNET,USB,UART
Sep 14 21:57:43 <thinkfat> maybe plugging the cable could help
Sep 14 21:57:55 <Guest83009> i mean what change have to make in it
Sep 14 21:58:14 <Guest83009> i need to customize it by my own.
Sep 14 21:59:03 <Guest83009> and need to know what changes have to make in rootfs too
Sep 14 21:59:05 <thinkfat> well. there's no NAND and no NOR on the bbb, so that covers two of your points
Sep 14 21:59:11 <set_> I found something on TI's Wiki a while back. Look there!
Sep 14 21:59:31 <Guest83009> could you give me the link plss
Sep 14 21:59:34 <thinkfat> for the others - how about plugging a cable?
Sep 14 21:59:51 <sicelo> i've just been reading about the PRUs ... very nice stuff. does RPi have something similar? (i know this might be sligtly OT question)
Sep 14 22:00:29 <set_> http://www.ti.com/sitesearch/docs/universalsearch.tsp?searchTerm=am335x&linkId=10&src=top&m=dd
Sep 14 22:00:30 <set_> ...
Sep 14 22:00:32 <thinkfat> if yes it's not documented
Sep 14 22:01:00 <set_> I found this a while back. It should work for you. There is unlimited pages to read and question.
Sep 14 22:01:28 <Guest83009> i download the bbb and i build an image file to it. i connected an ethernet cable to it, it works. but later after some time its unable to connect back to it
Sep 14 22:01:54 <set_> Did you change the image?
Sep 14 22:01:55 <CoffeeBreakfast> Plugging the eth cable in the BBB should work like in a Apple Mac Ad
Sep 14 22:02:08 <set_> Since?
Sep 14 22:02:25 <sicelo> win 29
Sep 14 22:02:59 <Guest83009> no i didnt change the image file, i worked on it from buildroot.
Sep 14 22:03:24 <thinkfat> buildroot, awesome stuff
Sep 14 22:03:30 <Guest83009> ya
Sep 14 22:03:30 <set_> Guest: Oh.
Sep 14 22:03:41 <set_> That is beyond me. I have not gotten into that.
Sep 14 22:04:17 <Guest83009> ok
Sep 14 22:04:22 <set_> bbl
Sep 14 22:04:32 <Guest83009> do you work on linux platform
Sep 14 22:05:36 <thinkfat> what do you mean
Sep 14 22:07:09 <thinkfat> must go now
Sep 14 22:07:14 <thinkfat> good night all
Sep 14 22:07:29 <Guest83009> good nt
Sep 14 22:11:28 <set_> Guest: So, you are looking into getting into Buildroot and not the image that the BBB.io people have given?
Sep 14 22:14:26 <set_> https://buildroot.org/downloads/manual/manual.html is a large manual.
Sep 14 22:14:27 <set_> ...
Sep 14 22:14:56 <set_> I can review real quickly and who knows? I may come up w/ something. Connecting by Ethernet! Got it!
Sep 14 22:18:39 <set_> Man Guest: That is some intense reading on specific ideas. Are you using a BBB or other related board?
**** ENDING LOGGING AT Sat Sep 15 03:00:25 2018