**** BEGIN LOGGING AT Sun Jul 01 02:59:59 2018 Jul 01 04:22:18 e Jul 01 08:12:40 Hello, I have joined IRC today itself. I would like to contribute in BeagleBoard. Where I can start ? Jul 01 17:52:05 people saying that (initially very odd sounding) "I would like to contribute" phrase are probably students who should be redirected to #beagle-gsoc ? Jul 01 18:05:51 yes, except gsoc is in progress, next one opens next spring Jul 01 18:07:49 There seem to be some schools/universities that either require or strongly encourage this. Leads to really weird situations of uninformed students encoutering reality though. Jul 01 18:11:43 interesting Jul 01 18:13:08 perhaps some schools/universities encourage contributing to open source projects as a student project, even if it's not part of gsoc? Jul 01 18:23:24 yes, indeed. many people arrive with no idea and only some example sentence from the leaflet "Hi, I want to contribute to your project, please guide me" Jul 01 18:34:23 lol, pru_virtqueue_add_used_buf() in the pru rpmsg lib is just... wrong Jul 01 18:36:39 of course it's disturbing in general that the whole lib doesn't contain even a single compiler barrier *anywhere*. maybe clpru is too dumb for this to ever be a problem, but then at the very least you want to use placeholder barriers "implemented" by a comment explaining this, so you know what to fix if the compiler ever gets smarter (or if you use gcc-pru) Jul 01 18:37:36 doing so would also have made this bug impossible Jul 01 18:55:38 ( https://pastebin.com/raw/fZ5XwsMD ) Jul 01 19:21:13 hi Jul 01 19:25:31 zmatt, where should i put that overlay with spi configuration in uEnv? Jul 01 19:25:51 sorry, what? Jul 01 19:26:32 * zmatt searches irc logs Jul 01 19:26:40 i mean= "for i in 17 18 21 22; do config-pin P9-$i spi; done" Jul 01 19:26:53 has nothing to do with uEnv.txt Jul 01 19:28:06 config-pin is simply a command you run, e.g. somewhere during startup or right before the application that needs it Jul 01 19:28:46 you write "do so by sticking it into right variable in /boot/uEnv.txt" Jul 01 19:29:06 *wrote Jul 01 19:30:16 no I didn't Jul 01 19:31:06 18:23:16 < zmatt> alternatively you can still use the overlay, but you do so by sticking it into the right variable in /boot/uEnv.txt Jul 01 19:31:21 yes Jul 01 19:31:22 "for i in 17 18 21 22; do config-pin P9-$i spi; done" is not an overlay, it's a line of bash script Jul 01 19:31:45 you *either* use an overlay, *or* you use config-pin Jul 01 19:31:47 so what is that overlay? Jul 01 19:31:57 ok Jul 01 19:32:03 my bad Jul 01 19:32:28 if you enable an overlay, "cape-universal" is automatically disabled and config-pin will no longer work Jul 01 19:32:36 so that's why it's either-or Jul 01 19:34:55 after config-pin flashrom says "no eeprom/flash device found" Jul 01 19:35:17 while everything is connected Jul 01 19:35:44 did you specify the correct device? Jul 01 19:37:37 i use that flashrom -p linux_spi:dev=/dev/spidev1.0,spispeed=512 Jul 01 19:38:12 which /dev/spidev* devices does your system have Jul 01 19:42:04 1.0 1.1 2.0 2.1 Jul 01 19:42:33 i don't have 0.0 or 0.1 Jul 01 19:42:43 then beware that spidev1.* means spi0 Jul 01 19:43:48 yes? Jul 01 19:44:01 (on these kernels spidev numbering isn't even fixed actually: they're sequentially assigned numbers by the driver, starting with 1. In later kernels this problem was solved) Jul 01 19:44:38 ah right those four pins are indeed for spi0 Jul 01 19:45:33 maybe double-check that they are indeed configured to spi function using my show-pins script: https://github.com/mvduin/bbb-pin-utils/#show-pins Jul 01 19:46:53 i will Jul 01 19:48:10 if that's not it, the most likely suspect is a problem with your wiring (including signal integrity issues maybe) or the flash chip. Jul 01 19:48:18 do you know why i don't have /sys/devices/bone_capemgr./slots ? Jul 01 19:48:30 because you're not using an ancient version of debian? Jul 01 19:49:23 it was /sys/devices/bone_capemgr.*/slots in kernel 3.8 Jul 01 19:49:39 it became /sys/devices/platform/bone_capemgr/slots in kernel 4.x Jul 01 19:49:47 it disappeared entirely with the introduction of u-boot overlays Jul 01 19:50:08 (i.e. capemgr now lives in u-boot instead of the kernel) Jul 01 19:57:41 so as i understand that overlay is old method described in libreboot docs Jul 01 19:58:16 yes Jul 01 19:59:17 and i can use it but in kernel 4.1 i should use other path to bone capemgr Jul 01 19:59:42 like I said, overlays are still supported, but you configure them in uEnv.txt Jul 01 20:00:30 I think even the old bone_capemgr is still around (albeit deprecated) and should show up when u-boot overlays are disabled in /boot/uEnv.txt Jul 01 20:00:57 but I really don't expect that different ways of enabling the spi port are going to make any difference Jul 01 20:01:24 if the spidev exists (it dose) and the pin are muxed right (verify that using show-pins), you're good to go Jul 01 20:01:36 *does Jul 01 20:02:37 if you still have problems at that point, it's most likely either the program you're using (flashrom), the spi target, or the connection to the spi target Jul 01 20:03:26 if the spi pins are configured right but you have any doubts about whether spi is working at all, connect mosi to miso and perform a simple loopback test Jul 01 20:04:16 When I was trying to use my bone for SPI things my issue turned out to be due to cable length more than anything Jul 01 20:04:35 (you can probably find a simple tool to perform spi transfers, or use something like py-spidev) Jul 01 20:04:38 i will try old method first Jul 01 20:04:45 that is utterly pointless Jul 01 20:04:54 did you check the pins already with show-pins? Jul 01 20:05:30 mm__: what distro are you using on the beagle? I had issues trying to get Arch ARM to work but it worked right away with debian. Jul 01 20:05:39 (okay maybe it's not utterly pointless, but it's not the most logical thing to do first) Jul 01 20:05:59 zmatt, not yet Jul 01 20:06:06 mm__: then that is step 1 Jul 01 20:06:18 Jonimus, i use debian jessie Jul 01 20:06:22 ok Jul 01 20:06:25 jessie? Jul 01 20:06:39 that's really old. did that even have 'config-pin' yet? Jul 01 20:06:46 yes Jul 01 20:07:30 it is debian 8.3 with kernel 4.1 Jul 01 20:07:36 that's so ancient /o\ Jul 01 20:07:48 a lot of bugfixes and improvements have been done in the spi driver since then Jul 01 20:08:01 please just use the latest system Jul 01 20:08:56 ^ Jul 01 20:09:23 seriously, latest just worked for me when i fought Arch ARM also(4.1 iirc) for hours. Jul 01 20:12:49 note: I think the latest images use kernel 4.14, which iirc fixed the spidev numbering bug, so be mindful of that (i.e. it would be /dev/spidev0.0 there) Jul 01 20:15:02 (I wanted to quickly very that, but the bbb at work where I installed a different kernel doesn't seem to come up anymore after reboot. oh well, I'll fix that in the morning) Jul 01 20:15:06 *verify that Jul 01 21:47:27 zmatt, show-pin says pins 17 18 21 22 are "spi boot clk/in/out/cs" Jul 01 21:50:46 as the README explains, that's merely the pin description. the selected mode is on the right side Jul 01 21:58:08 all four is (spi0_pins_s0) Jul 01 22:03:36 with "on the right side" I didn't mean literally the last bit of info on the line :P that's actually the pinmux node name, but it's good enough anyway... it clearly indicates the pin is used for spi Jul 01 22:03:49 (again, see README for a description of the columns) Jul 01 22:03:59 "spi0_pins_s0" is a weird as hell pinmux node name though Jul 01 22:04:03 never seen that before Jul 01 22:05:05 ah it's because you're using the old BB-SPI0 overlay. ok Jul 01 22:05:33 for 17 it is spi 0 clk Jul 01 22:05:43 yeah that's the pin mode Jul 01 22:05:59 for 18 it is spi 0 d0 miso Jul 01 22:06:14 yes yes all four are spi Jul 01 22:06:22 for 21 it is spi 0 d1 mosi Jul 01 22:06:31 nice Jul 01 22:07:57 but still flashrom says no eeprom/flash device found Jul 01 22:08:31 told you it was pointless to test the old way of enabling spi :) Jul 01 22:08:55 i guess that bbb pins are not the problem right now Jul 01 22:09:15 but i use old method :) Jul 01 22:10:20 anyway, im happy that spi works Jul 01 22:10:49 you can use whatever method you like. please do use a recent image (and therefore kernel) though... it's silly to use an obsolete debian release and an old kernel Jul 01 22:11:11 now i need to check whats going wrong with other parts Jul 01 22:12:43 (atx, pomona, and all cables) Jul 01 22:12:49 maybe you can run BeagleLogic on your bbb and use that to analyze what's going on on the spi bus ;) Jul 01 22:14:41 good idea Jul 01 22:15:13 first i will try with self-compiled flashrom Jul 01 22:15:57 if you know which spi flash it is, look up the datasheet and try a manual spi transfer (e.g. the identification command) Jul 01 22:17:11 i probably will Jul 01 22:17:25 tomorrow Jul 01 22:18:49 or grab https://liktaanjeneus.nl/spi-trace.so.tar.gz and invoke flashrom with this environment variable set: LD_PRELOAD=path/to/spi-trace.so Jul 01 22:19:03 it's a really hacky spi tracer I once made, and I don't know how robust it is Jul 02 00:08:08 Something is wrong w/ the BBB.io site. Are people working on this project still? Jul 02 00:08:25 works fine for me Jul 02 00:08:36 Oh? I will check again. Jul 02 00:09:08 Yep. It works now. Odd days, Montgomery. Jul 02 00:09:38 ... Jul 02 01:03:35 Before i use the BBB to set up Radio operations, I was trying to use two XBee modules w/ power to set up a LED. Jul 02 01:03:55 Would anyone like to see my configuration via hardware before I explode over here? Jul 02 01:04:14 brb Jul 02 01:09:04 Otay... Jul 02 01:09:06 Sorry. Jul 02 01:09:29 Any radio fans here? Jul 02 01:22:29 Scratch that. I got it. Jul 02 01:26:07 Now...onto the BBB! Jul 02 01:26:26 Wireless if you are nasty! Jul 02 01:50:07 Okay. Adding the XBee to the BBB got complicated. Boo! I found some Python scripts for the LED usage, though. Jul 02 01:50:08 ... Jul 02 01:50:20 Are there any people in here working w/ XBee and the BBB? Jul 02 01:56:54 ... Jul 02 01:57:41 I found an issue. I need to have Python3 running instead of Python2 when using pip to install the digi-xbee library. Jul 02 01:57:53 How can I make sure I am using python3 on my BBBW? Jul 02 01:59:44 use pip3 ? Jul 02 01:59:56 in general, be explicit which one you want Jul 02 02:00:43 Dang it. I just remembered. Jul 02 02:01:06 I have to install it via sudo apt install python3-pip. Jul 02 02:01:08 Yikes. Jul 02 02:01:14 My brain is haywire today. Jul 02 02:01:39 python 3 is what you normally want since python 2 is barely maintained anymore (EOL has been postponed from 2015 to 2020), but for backwards compatibility reasons the default python in debian is still python2 Jul 02 02:01:59 ... Jul 02 02:02:05 Nice to know. Jul 02 02:02:35 I have been using both and trying to switch over. There are not all that many differences from what I have found. Jul 02 02:02:35 ... Jul 02 02:03:10 I mean. the print statement and that is about it. Oh and quotation marks too. Jul 02 02:03:20 bytes vs strings Jul 02 02:03:37 Oh? Jul 02 02:03:46 What do you mean? Jul 02 02:04:11 "foo" is an utf-8 string (type 'str') Jul 02 02:04:27 b'foo' is a sequence of three bytes (type 'bytes') Jul 02 02:04:48 Oh. Jul 02 02:05:13 Now I know. Jul 02 02:05:28 this distinction introduces a lot of sanity Jul 02 02:05:47 I said "utf-8 string", I meant unicode string Jul 02 02:05:55 Uni! Jul 02 02:05:59 for a 'str' object, the actual representation is irrelevant to the programmer Jul 02 02:06:13 Oh. Jul 02 02:10:28 Hey zmatt: Is the com port/USB on the BBB called anything in particular? Jul 02 02:10:41 for example, the pile of poo character is a unicode string of length 1 (one codepoint): Jul 02 02:10:44 python3 -c 'x = chr(0x1F4A9); print( type(x), len(x) )' Jul 02 02:11:02 encoded as utf-8, it is four bytes: Jul 02 02:11:05 python3 -c 'x = chr(0x1F4A9).encode("utf-8"); print( type(x), len(x) )' Jul 02 02:11:21 I have no idea what you mean by that question Jul 02 02:11:41 I have a XBee dev. board attached to the BBBW. Jul 02 02:11:47 via USB. Jul 02 02:12:41 anyway, as closing remark: since plan is to change the default eventually, avoid ever using "python", especially in scripts. Always explicitly use python2 or python3 Jul 02 02:12:55 okay. Jul 02 02:13:40 I thought xbee modules connected via uart, not usb ? Jul 02 02:13:59 why would you connect a dev board to the beaglebone rather than connecting the module itself? Jul 02 02:14:00 I have a dev. board attached to my XBee. Jul 02 02:14:12 To try to test it out. Jul 02 02:14:27 I mean, I could just use the lines and pins. Jul 02 02:14:52 I thought the USB could "know" my board and know it was attached to a XBee. Jul 02 02:15:18 I'm not sure what you mean by "use the lines and pins", but don't try to connect to the xbee module while it's connected to the dev board :P Jul 02 02:15:34 sorry. wires and pins (Header Pins). Jul 02 02:15:44 Okay. Jul 02 02:15:51 you're making unreasonable expectations from usb Jul 02 02:16:04 Even w/ a serial interface via PuTTY? Jul 02 02:16:14 presumably the dev board declares itself as *some* sort of device, but I have no way to magically know as what Jul 02 02:16:18 check kernel log Jul 02 02:16:30 or lsusb Jul 02 02:16:34 Okay. Jul 02 02:16:36 Please hold. Jul 02 02:17:17 Bus 001 Device 002: ID 0403:6001 Future Technology Devices International, Ltd FT232 USB-Serial (UART) IC Jul 02 02:17:33 well, it declares itself as a serial port, there ya go Jul 02 02:17:38 Yea! Jul 02 02:17:45 I'm guessing this "dev board" is actually just an ftdi usb-serial adapter? :P Jul 02 02:18:10 Probably. The Digi people made it and then discarded it. Jul 02 02:18:20 It was in circulation for only a couple of months. Jul 02 02:18:37 there's no info about it? Jul 02 02:18:40 I got it. Oops but that cmd lsusb does it well. Jul 02 02:18:58 There is but it is vague. Jul 02 02:19:06 Not too much about it these days. Jul 02 02:19:17 THT dev board Jul 02 02:19:35 from Digi International. Jul 02 02:19:49 Grove dev. board. Jul 02 02:20:54 https://www.google.com/images?q=digi+tht+dev+board which of those is it? :P Jul 02 02:22:09 https://www.google.com/search?q=digi+tht+dev+board&tbm=isch#imgrc=HhIF7tIuBZ3NTM: Jul 02 02:25:31 three grove adapters per side. Jul 02 02:26:13 it has actual docs -> https://www.digi.com/resources/documentation/digidocs/pdfs/90001457-13.pdf Jul 02 02:28:18 I know. Jul 02 02:28:22 I read over and over. Jul 02 02:28:57 They offer not too much. I did start on the Python scripts w/ the XBee modules, though. Jul 02 02:29:32 so yeah, it's not much more than an ftdi usb-serial converter and a bunch of connectors and pcb traces connecting them :) Jul 02 02:29:59 and a few leds Jul 02 02:30:26 Okay. So, since this device can be attached via USB, does this give me an advantage when connecting to Serial (USB) on the BBB? Jul 02 02:31:18 It is a cool dev. board but I lack my older book on conecting to the BBB via Serial and PuTTY> Jul 02 02:31:34 in real time. Jul 02 02:32:05 it saves four expansion header pins, but uses up the usb host port (unless you use a hub) and has worse performance probably. usb on the bbb also has a reputation for being fickle sometimes Jul 02 02:32:46 Okay. Jul 02 02:33:09 I hooked up this dev. board years ago and used PuTTY via their serial console to sent in AT cmds. Jul 02 02:33:40 ...I was connected to the BBB via the USB w/ this particular THT dev. board. Jul 02 02:35:17 yes, you can similarly send AT commands to it when connected to the beaglbone Jul 02 02:35:37 usb serial device is slightly simpler than a real uart since the port itself requires no configuration Jul 02 02:36:03 Right. Jul 02 02:36:30 But now, they have Python3 as a language to use for these connections. Jul 02 02:36:49 sounds fine Jul 02 02:37:20 I guess this is the question. Can I use python in a serial terminal via PuTTY on the BBB while on the BBB's linux Distro? Jul 02 02:37:21 ... Jul 02 02:37:23 Sorry. Jul 02 02:37:56 * zmatt stares at the question Jul 02 02:38:02 Odd heh? Jul 02 02:38:15 it's funny... all words are familiar to me, yet they combine to mean nothing Jul 02 02:38:21 It works. I just lost my damn book. Jul 02 02:38:31 Hahahah. Jul 02 02:39:22 you connect using putty to the beaglebone. on the beaglebone, python software uses serial to communicate with the xbee. those two things have nothing to do with each other really Jul 02 02:39:46 Oh. Jul 02 02:39:50 But it can work. Jul 02 02:40:39 what are you managing to fail here? Jul 02 02:40:55 Hey zmatt: Do you want to see their idea of what "could" work on pastebin? Jul 02 02:41:13 Sorry. The people on digi xbee python library on GitHub. Jul 02 02:41:22 the board appears as serial port on the BBB? (it would /dev/ttyUSB* or /dev/ttyACM* I think) Jul 02 02:41:31 (see also kernel log, it will be mentioned there) Jul 02 02:41:32 Oh! Jul 02 02:41:39 how do I see kernel log? Jul 02 02:41:43 dmesg Jul 02 02:41:48 Oh...oops. Jul 02 02:42:23 but in this case it may be easier to type ls /dev/ttyUSB* /dev/ttyACM* than to try to find the right message in the kernel log Jul 02 02:42:34 ttyUSB0? Jul 02 02:42:41 sounds good Jul 02 02:43:13 it is located in dmesg at usb 1 - 1 Jul 02 02:43:40 so make sure the software you're trying to use also knows that ttyUSB0 is the xbee and it should work Jul 02 02:43:48 also, make sure the switch on the dev board is set to Normal Jul 02 02:43:54 Okay. Jul 02 02:45:14 I am about to add the software w/ the ttyUSB0 instead of the norm, e.g. "port." Jul 02 02:46:14 "port." ? Jul 02 02:46:19 what Jul 02 02:46:21 sorry. com Jul 02 02:46:27 again what? Jul 02 02:46:33 can you link to this python code? Jul 02 02:46:40 Sure. Please hold. Jul 02 02:47:26 also keep in mind that python also runs on Windows, so it is very well possible for examples to be for that (which is what COMx as serial port name would suggest) Jul 02 02:47:49 https://pastebin.com/HwDGvEHX Jul 02 02:47:51 I got you. Jul 02 02:48:04 I get that idea messed up sometimes. Jul 02 02:49:48 yep, that "COM1" should be "/dev/ttyUSB0" for you Jul 02 02:50:23 I got it. Jul 02 02:50:41 That is not the issue now. I am stuck w/ errors up the wang. Jul 02 02:51:14 then something is wrong, and based on past experiences there's a fair chance that in fact you're doing it wrong Jul 02 02:51:25 I know. Jul 02 02:51:27 I am sure of it. Jul 02 02:51:27 ;) Jul 02 02:51:33 ? Hahahahah. **** ENDING LOGGING AT Mon Jul 02 03:00:00 2018