**** BEGIN LOGGING AT Mon Mar 26 03:00:02 2018 Mar 26 03:43:05 windsurf_: just checkout the appropriate branch of dtb-rebuilder and replace this line: https://github.com/RobertCNelson/dtb-rebuilder/blob/4.9-ti/src/arm/am335x-pocketbeagle-common.dtsi#L490 by one of the other options, e.g. line 492 Mar 26 03:43:12 recompile the dtb and you're done Mar 26 03:43:23 (well, recompile and install it) Mar 26 03:43:57 Hi Mar 26 03:45:06 zmatt thanks, did you just make that file or is that the same file we were looking at before to discover which was the default? Mar 26 03:45:18 the latter Mar 26 03:45:36 is a device tree overlay the same as the device tree in terms of the file type and syntax? Mar 26 03:45:51 sorta Mar 26 03:46:01 kinda Mar 26 03:46:07 does it matter which version of the kernel we have? Mar 26 03:46:22 so is this file an overlay and not the device tree? Mar 26 03:46:36 somewhat, so pick the branch for the kernel series you're using Mar 26 03:46:45 this file is an include file for the main device tree Mar 26 03:46:54 there are no overlays in the dtb-rebuilder repository Mar 26 03:47:37 ok – so whose repository is this? Mar 26 03:47:55 robert c nelson's ? Mar 26 03:47:56 is this repo only the device tree or is it the whole kernel? Mar 26 03:48:17 it has a readme :P Mar 26 03:48:17 what's dtb, device tree builder? What does that mean? Mar 26 03:48:26 i'll read RTFM Mar 26 03:48:27 device tree blob/binary Mar 26 03:48:36 i.e. a compiled device tree Mar 26 03:49:13 i see Mar 26 03:49:46 so compiling this compiles the device tree for pocket beagle (and the repo contains a bunch of other ones we won't use) Mar 26 03:50:02 the dtb-rebuilder repository is meant to make it easy to recompile dtbs without recompiling the whole kernel (which is when dtbs are compiled normally) Mar 26 03:50:44 yeah you can just compile a specific dtb with e.g. make src/arm/am335x-pocketbeagle.dtb Mar 26 03:51:25 what's dts vs dtsi? Mar 26 03:51:48 dts = device tree source, dtsi = include file Mar 26 03:52:07 ok i'll try that. I don't have my device with me atm unfortunately Mar 26 03:52:10 I will tomorrow Mar 26 03:52:27 oh so the dtsi is included in the dts? Mar 26 03:52:31 yes Mar 26 03:52:34 gotcha Mar 26 03:52:52 i think I could try compiling this in a docker image I have, might work just to try it Mar 26 03:53:01 container not image Mar 26 04:02:50 actually gonna go out and get my device.. Mar 26 04:03:21 zmatt so after I compile it, I'll have to figure out what binary file it produces and where and how to then apply that to my OS Mar 26 04:03:52 'make src/arm/am335x-pocketbeagle.dtb' already says which file it's producing Mar 26 04:04:20 the place to put it is /boot/dtbs/$uname_r/ where $uname_r is your kernel version Mar 26 04:06:41 did you mean make....dts ? Mar 26 04:06:50 no Mar 26 04:09:02 I think I'm missing `/usr/bin/dtc` Mar 26 04:09:29 you'll need dtc yes Mar 26 04:10:47 I'm going to go get my device, I don't know if this container on OS X is the same enough Mar 26 04:10:56 back in 20 Mar 26 04:11:21 once that file is in /boot (which in my container is empty – hopefully not on actual device), do I just reboot and it should overlay and just wokr? Mar 26 04:11:55 it's not an overlay, but other than that yes Mar 26 04:14:35 it's the device tree binary Mar 26 04:14:37 right? Mar 26 04:14:46 i'm modifying the source of that directly rather than overlaying? Mar 26 04:14:54 can't wait to try brb Mar 26 04:14:56 yup Mar 26 04:15:30 you could also patch this with an overlay, but it's a bit more annoying in practice Mar 26 04:15:38 yeah not important to me Mar 26 04:15:45 this feels clean enough Mar 26 04:53:18 back with device Mar 26 04:53:23 yep I have dtc here Mar 26 05:06:45 looks like it worked zmatt . thanks! Mar 26 05:12:53 hi.. i have used beaglebone write a code in c and python working well ...not working after reboot using debian os..can you give any solution... Mar 26 05:14:42 siru_ your program worked then you rebooted and it no longer does? Mar 26 09:00:03 Hey I could use some help in connecting to the expansion slots on the x15 Mar 26 09:00:24 They aren't regular GPIO plugs so I'm a bit lost Mar 26 09:01:11 I think the connectors are documented with part numbers for digikey Mar 26 09:01:15 they're not very friendly for experimentation indeed Mar 26 09:01:37 probably in the SRM Mar 26 09:02:33 No it doesnt seem to friendly for plug and play Mar 26 09:02:49 does anyone have the link to the SRM? Mar 26 09:05:04 https://github.com/beagleboard/beagleboard-x15 Mar 26 09:18:37 thanks, I never have that at hand when I need it :) Mar 26 09:20:21 neither do I, but there's this thing called "google", it's awesome Mar 26 09:21:07 I'll have to try that some day! Mar 26 09:21:18 hehe Mar 26 15:19:16 hello every body. Mar 26 15:19:50 I want to connetct my Android smart phone to Beagle bone black Mar 26 15:20:27 and get access to my external sd-card. Mar 26 15:21:34 uname -a Linux arm 4.14.11-ti-r22 #1 SMP Thu Jan 4 22:52:45 UTC 2018 armv7l GNU/Linux Mar 26 15:22:51 root@arm:~# dmesg -c Mar 26 15:22:58 [ 3045.570488] usb 1-1: new high-speed USB device number 7 using musb-hdrc Mar 26 15:23:04 [ 3045.719542] usb 1-1: New USB device found, idVendor=04e8, idProduct=6860 Mar 26 15:23:06 please don't paste multi-line output in the channel Mar 26 15:23:11 use a paste service like pastebin.com Mar 26 15:23:13 [ 3045.719560] usb 1-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 Mar 26 15:23:31 [ 3045.719568] usb 1-1: Product: SAMSUNG_Android Mar 26 15:23:37 [ 3045.719574] usb 1-1: Manufacturer: SAMSUNG Mar 26 15:23:43 [ 3045.719580] usb 1-1: SerialNumber: 5200f875f46015ff Mar 26 15:24:09 . Mar 26 15:24:48 How can I mount and list and manipulate my sc-card? Mar 26 15:26:22 what you've pasted so far doesn't indicate anything about the connected device being a mass storage device. unless there was more output after this, it looks like the phone presents itself as an unrecognized type of device Mar 26 15:29:42 zmatt: when I connect my phone to a ubuntu PC, two partition are recognized. one internal storage and one external sd-card. Mar 26 15:30:53 zmatt: but on beagle bone no block partition is recognized.! Mar 26 15:32:07 which means the phone doesn't behave like a regular usb storage device, but ubuntu probably includes some additional driver or software to allow the phone to be recognized Mar 26 15:33:17 zmatt: surely. Mar 26 15:34:55 zmatt: in ubuntu pc the message "Allow access to phone data? is poped up on smart phone, but no message while connecting to BBB!. Mar 26 15:37:06 any comment? Mar 26 15:37:13 no idea? Mar 26 15:39:46 no, like I said there's evidently some extra software on ubuntu that handles this, but I have no idea what that is Mar 26 17:02:28 when powering the bbb through the pins (5v to vdd, pin5&6 on p9), the usb socket doesn't provide 5v Mar 26 17:02:38 if I power through the jack - it seems to. Mar 26 17:03:00 I thought the jack and vdd were connected so this makes no sense to me Mar 26 17:04:46 that indeed doesn't make sense Mar 26 17:05:36 P9.05+P9.06 are connected directly to the center pin of the 5v jack Mar 26 17:05:49 they are literally the same thing Mar 26 17:06:18 and the usb host port should provide power regardless of how the system is being powered Mar 26 17:06:36 (unless it's disabled or in a fault state of some sort) Mar 26 17:08:35 I just put my scope on the power pin of the usb board I'm trying to use Mar 26 17:08:45 and it's not that it's differnt one from the other Mar 26 17:08:52 it's that sometimes its on and sometimes it's off Mar 26 17:09:18 it just happened to line up with the few times I tried it Mar 26 17:09:19 sounds like maybe vbus errors of some sort, check kernel log Mar 26 17:10:34 ok Mar 26 17:11:35 these can be caused if the usb device has too much inrush current, due to the lack of adequate output cap on the bbb's usb host port 5v Mar 26 17:13:00 (iirc 100 uF is recommended, 0.1 uF is present) Mar 26 17:14:54 ok I just watched it go down Mar 26 17:15:07 it starts off fine (well about 4v, so not really fine) Mar 26 17:15:20 4v is not remotely fine Mar 26 17:15:45 4v should result in the power being shut down due to overcurrent Mar 26 17:17:17 starts off at 5v, then drops to about 4.1 when the lcd screen's backlight comes on Mar 26 17:17:35 vdd stays at 5v the whole time Mar 26 17:17:38 sounds like it's simply drawing way too much current Mar 26 17:19:09 maybe I should power the board off my main 5v Mar 26 17:19:57 if it has some way to receive power other than via its usb port, that would be a good idea yes Mar 26 17:21:25 you might remember I was asking about audio on the bbb and using i2s. wanted to do the audio that way Mar 26 17:21:54 but the lcd sheild I'm using uses one set of spi pins and the other spi pins I need for other parts of the system Mar 26 17:22:20 so I think usb is the only other way Mar 26 17:22:44 I did look at trying to get audio off the hdmi signal. but not sure if thats compatible with using the lcd shield anywhayl Mar 26 17:22:48 anyway Mar 26 17:23:21 looks like that usb board is using about 100 ma max. Mar 26 17:23:39 anyway, it's not a problem to take power from elsewhere Mar 26 17:26:12 100 mA should not be a problem Mar 26 17:26:24 so I suspect that's not true Mar 26 17:28:19 unless you're using a really crappy usb cable perhaps having 10 ohms of resistance on the 5v wire Mar 26 17:30:27 1.6 ohm Mar 26 17:30:46 fairly crappy looking cable to be fair Mar 26 17:33:01 100 mA * 1.6 Ω is still only 0.16 V voltage drop, so that can't explain measuring 4.1 V Mar 26 17:34:36 could be +ve wire is nice conductor and well connected but just too thin Mar 26 17:34:56 its an audio dac with a usb A plug on it. Mar 26 17:35:13 I've got it jacked direct in now but soldered wires onto the +ve so I can still see what's happening Mar 26 17:38:31 4.88v, and beagle seems to boot and play audio fine now Mar 26 17:38:36 I'll reboot it a few more times to be sure Mar 26 17:41:52 Hello.! I am a robot enthusiast and quite good with arduino,beagle board and the raspberry pi..but is it too late to submit a proposal now Mar 26 17:42:20 given I haven't discussed much about the project Mar 26 17:42:38 anyone..? Mar 26 17:42:48 what is the proposal for? Mar 26 17:42:54 this is a general channel about beaglebone Mar 26 18:35:06 hello. I wonder that BeagleBoard-X15 has RS-422? Mar 26 18:35:43 If I purchase X15 then can I use RS-422? Mar 26 18:36:45 if you design an expansion board for it with an RS-422 transceiver, sure Mar 26 18:36:59 Thank you so much Mar 26 18:37:27 it could probably be a tiny board that plugs into one of the four expansion connectors Mar 26 18:38:18 OK @zmatt, thank you so much. Good bye. Mar 26 18:38:35 after all it has 7 UARTs Mar 26 18:40:06 10 Mar 26 18:40:30 SRM said 7 Mar 26 18:40:50 hmm, maybe the remaining three aren't accessible via the expansion headers? that still sounds odd to me though Mar 26 18:41:25 yeah odd Mar 26 18:42:42 nope, it seems 9 out of 10 uarts are accessible Mar 26 18:42:47 (plus the two pruss uarts) Mar 26 18:45:27 neat Mar 26 18:50:53 https://pastebin.com/raw/z78jcqtp Mar 26 20:19:24 I have a BBB Rev C using Debian GNU/Linux 8.2 (jessie) and kernel 4.1.13-ti-r30 and I haven't been able to flash it's eMMC to another image that I have, it's a customized one, but based on Debian GNU/Linux 7.9 (wheezy) and kernel 3.8.13-bone79 Mar 26 20:19:31 Could anyone help? Mar 26 20:20:31 wheezy with a 3.8 kernel... sounds like you need an archeologist? ;-) Mar 26 20:21:06 yeah, sounds like. Mar 26 20:21:39 Also I haven't been able to downgrade the recent one to the kernel 3.8 Mar 26 20:21:48 is it a recently produced BBB? can you tell me the part number that's on the eMMC chip? Mar 26 20:23:29 or wait, perhaps simpler: if you boot from an sd card that contains your ancient system, does eMMC even show up at all as block device? Mar 26 20:24:21 Hi ZMATT, yes it is possible to boot from sd card. Mar 26 20:24:42 yes but once booted, does it detect the eMMC ? Mar 26 20:25:06 I've not noticed that Mar 26 20:25:11 I'll check Mar 26 20:26:58 since I know that sufficiently recently produced BBBs have an eMMC that's too modern to be supported by 3.8 kernels. it's possible that rcn may perhaps have applied a patch to fix that, but then you'll need to upgrade the kernel to the latest in the 3.8-bone series Mar 26 20:29:37 booting from sd card I have mmcblk0, mmcblk0p1 and mmcblk0p2 Mar 26 20:29:44 i.e. no eMMC Mar 26 20:29:49 so it's almost certainly this problem Mar 26 20:29:57 eMMC is too modern to be supported by your kernel Mar 26 20:30:17 i see Mar 26 20:30:34 i'll try to upgrade the kernel from sd card Mar 26 20:30:34 you can try upgrading to the latest 3.8-bone kernel and see if that helps Mar 26 20:54:34 zmatt I'm still upgrading, but tks for the tips, they make sense as when I try to flash it answers that /dev/mmcblk01 doesn't exist Mar 26 21:48:44 I would like to manage all my beaglebones on the network using ethernet and a switch – I think that means I'd like to change the host from beaglebone.local to mybb1.local, mybb2.local... how do I do that and is that the right approach? Mar 26 22:12:09 found it Mar 27 01:41:00 Hello! Mar 27 01:41:48 I ordered some wiring for the BBBlue. I am waiting until they show up. I plan on doing something w/ the BBBlue, too. Mar 27 01:41:50 Just wait! Mar 27 01:59:27 What soldering iron tip should I use w/ the Pocket Beagle? Say I want to solder on some items to make the Pocket Beagle work w/out ruining the hardware, what tip is preferable? Mar 27 02:01:30 Pen tip, chisel tip, and etc... Mar 27 02:01:32 ... Mar 27 02:17:01 Hi all, Mar 27 02:22:31 I have my BBB running a basic python script to write a byte of data on an endless loop via i2c-2. However, reading the i2c SCL line with a scope shows that the voltage is constant and isn't toggling as you would expect. I was wondering how anyone here would use i2c on their BBB and whether writing a python script is an approach that anyone has taken. Mar 27 02:28:18 yassyass: incidentally, I just wrote my first code to interface with i2c yesterday. Mar 27 02:28:21 I wrote C rather than python, and am interfacing with one of these: https://www.sparkfun.com/products/11295 Mar 27 02:28:37 write a kernel driver Mar 27 02:29:20 interfacing via /dev/i2c* worked fine for me. But yeah, a kernel driver is also an option. Mar 27 02:29:45 Things pretty much worked as expected via the character device interface, fwiw Mar 27 02:34:52 noahm: that is interesting, how different is it to read from an i2c device such as in your case vs controlling a slave device and writing to its registers to run it a certain way? Mar 27 02:44:39 yassyass_: I'm not sure, tbh. like I said, I'm pretty inexperienced. afaict, the driver takes care of the lowest level details, e.g. ACK/NACK bits, etc. Mar 27 02:44:42 But I haven't been able to wrap my head around how the datasheet for my device relates to low level i2c protocol Mar 27 02:45:24 yes what's also really interesting is that it seems that there is not de facto method of writing code on the BBB, which in this instance for i2c Mar 27 02:46:29 I am more comfortable reading those data sheets and writing code for an 8bit microcontroller in C using something like CCS or IAR to compile and run Mar 27 02:47:13 but the BBB has been really interesting in that its capabilities show a lot of potential but from my point of view not a clear path to utilise them **** ENDING LOGGING AT Tue Mar 27 03:00:03 2018