**** BEGIN LOGGING AT Mon Feb 26 03:00:02 2018 Feb 26 03:05:54 beagle board (http://www.robotpower.com/products/osmc_info.html) might be able to control the newer 3.6 version Feb 26 03:07:46 Granted you aren't driving a motor cycle with it ... Feb 26 03:09:08 the BBB I believe has PWM outputs some of the more interesting bits might take work though level shifting etc will be needed 3.6 (https://groups.yahoo.com/neo/groups/osmc/files/OSMC-v3.6x/) Feb 26 03:15:00 GenTooMan: Hello. Feb 26 03:15:43 <<< smoke break Feb 26 03:20:24 GenTooMan: Are you still working on your project? Feb 26 03:21:47 Are there any Adafruit people in here right now? I am using my BBB w/ Motor Bridge Cape. Feb 26 03:21:48 ... Feb 26 03:22:06 I cannot find out which version of Adafruit_BBIO I am using. Help! Feb 26 03:25:16 1 no I don't use it 2 shouldn't there be documentation on how to find the version? Feb 26 03:25:46 Yea and yes. But...I am lacking knowledge on researching powers right now. Feb 26 03:25:51 ... Feb 26 03:25:56 I am coming up empty. Feb 26 03:26:16 I found the page on GitHub.com and at Adafruit.com. Feb 26 03:26:32 But...I am a terrible reader. I will go and search again. Feb 26 03:28:10 No go. Feb 26 03:29:32 Sometimes I feel as though I am making bad news for the BBB w/ all my interjections. Please feel free to add support. Feb 26 03:30:08 you have the software in your BBB right it should have information about its version in it. Look how to find it's version. Feb 26 03:30:30 Good software will tell you what it is in otherwords. Feb 26 03:31:02 Oh. Feb 26 03:31:23 Okay. I tested find Adafruit_BBIO and Adafruit_BBIO --version, too. Feb 26 03:31:27 No go. Feb 26 03:31:55 man Adafruit_BBIO ? Feb 26 03:32:08 IE does it have a manpage? :D Feb 26 03:33:28 It has a PyPI page. Feb 26 03:33:37 I will check man. Feb 26 03:34:22 No go. Feb 26 03:35:12 I bet it is some no I2C address having library that I cannot communicate the BBB on or w/ for now. Sense no make. Feb 26 03:35:28 ... Feb 26 03:35:36 Trust me. I will find the version. Feb 26 03:35:41 Trust me. Feb 26 03:35:43 Hhahaha. Feb 26 03:36:01 they say insanity is a state of mind. Feb 26 03:36:49 Right oh! I bet the I2C workings on this library does not exist anymore. I checked. They do not support the i2c function of the BBB w/ it any longer. Feb 26 03:37:21 They have PWM, UART, and SPI, and qEP. Feb 26 03:37:40 Oh well. Feb 26 03:39:08 I would update but then I cannot preserve specific functional aspects of this library/module. Feb 26 03:39:09 ... Feb 26 03:48:17 make a u-turn back to an older capable i2c set up. Feb 26 03:48:32 forget it. Feb 26 04:34:39 <<< trying to work w/ the system now... Feb 26 06:02:29 set_: uhh what are you talking about now? Feb 26 06:03:09 actually I don't even want to know, never mind Feb 26 06:10:03 Boom Town over here. Sorry. Feb 26 06:23:39 zmatt: If you are bored out of the wazoo, get this: I reverted back to a time when Adafruit_I2C worked on the BBB. Feb 26 06:23:52 i.e. w/ the Motor Bridge Cape. Feb 26 06:24:05 why would you do that instead of just using Adafruit_GPIO.I2C as the library tells you to? Feb 26 06:24:11 i change the library and software but I keep getting errors. Feb 26 06:24:25 B/c...that library no longer supports I2C. Feb 26 06:24:31 yes it does Feb 26 06:24:37 No...I tried it out. Feb 26 06:24:40 https://github.com/adafruit/Adafruit_Python_GPIO/blob/master/Adafruit_GPIO/I2C.py Feb 26 06:24:42 Numerous times. Feb 26 06:24:44 it's *right* *there* Feb 26 06:24:45 I read it, too. Feb 26 06:24:59 It does not matter what they are saying. Feb 26 06:25:08 I tested it. Feb 26 06:25:14 I'm not reading some documentation or anything, this is the source code, it's *right* *there* Feb 26 06:25:19 I know. Feb 26 06:25:22 I read it over. Feb 26 06:25:50 I see where they have it listed but w/ my Cape, their functionality on the I2C address/busnum is not quite right as of now. Feb 26 06:26:10 what do you even mean by that? Feb 26 06:26:21 I tested it and it does not work. Feb 26 06:26:22 all of the I2C libs have exactly the same "functionality on the I2C address/busnum" Feb 26 06:26:26 then you're just using it wrong Feb 26 06:26:30 Okay. Feb 26 06:26:48 Sure...I am wrong. I know. I may as well be. I get no resolve. Feb 26 06:27:27 zmatt: I changed the Adafruit_I2C.py software in the 1.0.05 software. Feb 26 06:27:28 have you installed the Adafruit_GPIO library? Feb 26 06:27:32 Yes. Feb 26 06:28:03 so you can now do: import Adafruit_GPIO.I2C as I2C Feb 26 06:28:03 ? Feb 26 06:28:11 Nope. Feb 26 06:28:14 It does not work. Feb 26 06:28:16 what's the error? Feb 26 06:28:26 Some carp's butt. Feb 26 06:28:30 what's the error? Feb 26 06:28:51 It points to a period, i.e. "." Feb 26 06:29:28 Just like you said. It says that this module Adafruit_I2C has been deprecated. use Adafruit_GPIO.I2C instead. Feb 26 06:29:54 that is not an error you can possibly get from that statement above Feb 26 06:29:54 I changed my software in the motor Bridge.py file. Feb 26 06:30:09 please just open python and execute this statement, and just this statement: Feb 26 06:30:12 import Adafruit_GPIO.I2C as I2C Feb 26 06:30:14 Okay. Feb 26 06:30:16 Please hold. Feb 26 06:31:06 NO module named ... Feb 26 06:31:12 okay so you didn't install it Feb 26 06:31:15 OH. Feb 26 06:31:31 So, I need it and Adafruit_BBIO? Feb 26 06:31:59 they're different libraries yes Feb 26 06:32:20 Okay. Now, I understand what you were saying a couple days ago. Feb 26 06:32:24 Sorry. Feb 26 06:37:55 same shit. Feb 26 06:38:01 Sorry...same stuff. Feb 26 06:38:24 ? Feb 26 06:38:50 Let me change the software some more. Feb 26 06:39:50 Bedtime. Later for now. Feb 26 06:40:00 Sorry to bug you. Feb 26 06:42:22 change what software? I thought you were going to install the Adafruit_GPIO library? Feb 26 08:11:02 has the method to enable /dev/ttyO1 changed in 4.4.48-ti-r88? Feb 26 08:16:59 Ionakka: the way has changed over time, although it's been the same for quite a while now. it's not really dependent on kernel version though, more on u-boot and configuration Feb 26 08:18:06 (it's also been /dev/ttyS1 rather than /dev/ttyO1 for a long long time now, although for backwards compatibility there's still a ttyO1 -> ttyS1 symlink, and similar for the other uarts) Feb 26 08:18:45 cape-universal has been enabled by default for quite a long time now, which means that on current images the uarts are enabled by default and only require setting the pinmux using config-pin Feb 26 08:34:31 zmatt: thanks! Feb 26 08:34:54 is there some documentation how the pinmux is configured? Feb 26 08:36:04 you should be able to find docs on config-pin yeah, but it's basically something like config-pin P9.24 uart and similar for other pins Feb 26 08:37:17 yeah it seems to be a simple tool Feb 26 08:37:26 do note that it's not persistent Feb 26 08:37:40 i was wondering whether there's some place where the boot-time configurations are written Feb 26 08:38:32 no, normally this stuff would be configured in device tree Feb 26 08:39:12 but because DTs are regarded as complicated and noone has yet made a tool that makes it easy to produce a custom DT, runtime configuration via config-pin is still the norm because it's simple to understand Feb 26 08:40:12 (overlays are also still used to some extent, although nowadays these are applied to the main DT by u-boot. runtime overlays done by the kernel are deprecated and will go away) Feb 26 08:40:39 does the applied by u-boot have something to do with uEnv? Feb 26 08:40:59 /boot/uEnv.txt is the configuration file for u-boot Feb 26 08:41:16 u-boot overlays are configured there Feb 26 08:42:19 thanks for verifying that Feb 26 08:43:27 i had previously cape_enable=bone_capemgr.enable_partno=BB-UART1 but removing that didn't seem to have effect Feb 26 08:43:47 it seems that ADC that used to work with older kernel (4.4.30) doesn't work as well Feb 26 08:44:03 if u-boot overlays are enabled, 'cape_enable' has no effect Feb 26 08:44:12 adc should work and be enabled by default Feb 26 08:44:36 which image are you using exactly? since I'm pretty sure the current default kernel series is 4.9-ti, not 4.4-ti Feb 26 08:44:55 but maybe I'm wrong Feb 26 08:45:10 i've built one with 4.4.48-ti-r88 Feb 26 08:45:46 built one? Feb 26 08:46:26 the configs (and other things in image-builder repo) are somewhat outdated as the support for qemu was dropped (i rather disabled doing the python things which behaved with undeterministic fashion under qemu) Feb 26 08:46:56 oh I've never used image-builder Feb 26 08:47:19 ./RootStockNG.sh -c my-config etc Feb 26 08:48:23 well i might be missing some things but it looks like i need to check the device trees... "complicated" is subjective description but would there be some decent documentation on the device trees? Feb 26 08:48:48 there's definitely documentation, "decent" is subjective ;) Feb 26 08:49:04 it's in Documentation/device-tree in the kernel docs Feb 26 08:50:05 you can of course also look at existing dts files, although many are way messier and harder to read than necessary Feb 26 08:50:26 you can also look at the various .dtsi files in https://github.com/mvduin/overlay-utils Feb 26 08:50:35 these are small dts snippets that enable various functionality Feb 26 08:51:37 (a dts file typically consists of #including some base .dtsi for the SoC and adding small snippets like these on top of that to enable/configure the stuff you need) Feb 26 08:52:09 zmatt: thanks! Feb 26 08:52:15 i have something to start reading from Feb 26 08:53:29 one thing you'll want to know to understand what you're reading: &label is a reference to an existing node labeled with label: Feb 26 08:54:14 (these labels are global across the whole DT) Feb 26 09:55:29 In BeagleboneBlack, SPI1 is connected to TDA19988BHN (LCD to HDMI). If I disable HDMI in linux and I use for other electronic peripheral, can occur a collision, since it still connected to the mentioned chip? Feb 26 09:57:21 yes Feb 26 09:57:30 or no? Feb 26 09:57:56 depends on whether there is a chip select signal that can quiesce the hdmi chip Feb 26 09:58:39 if yes, it might work, you just have to be aware of the capacitive load added by the hdmi chip Feb 26 10:00:56 Thank you, Other doubts, is it possible remap chip select pin. I want to use chip select by hardware because it is faster than software. Even I will use a DAC and proably I will use 20MHz Feb 26 11:24:35 spi? what? Feb 26 11:24:42 the tda19988 has no spi interface Feb 26 11:25:25 if you disable hdmi via /boot/uEnv.txt, none of the expansion header pins are in use for hdmi Feb 26 11:28:16 the pins for spi1 are actually only used for hdmi audio, hence disabling hdmi audio in /boot/uEnv.txt should suffice to free up those pins Feb 26 11:28:58 and yes the hdmi framer will still receive those signals, but it shouldn't matter since the audio functionality should be disabled entirely by the kernel driver Feb 26 11:29:29 if you disable hdmi entirely, then the hdmi framer remains in standby mode and will not care about any of its pins Feb 26 11:30:33 I doubt the capacitive load matters much at 20 MHz Feb 26 11:35:29 Hi there, Feb 26 11:36:03 I'm looking the way to boot a custom board based on BBB design from NAND flash Feb 26 11:36:19 What is the right way to configure uboot for this? Feb 26 11:36:37 NAND flash is MT29F4G16ABADAWP Feb 26 11:41:15 zmatt: I remember struggling to have a wlan and a flash chip both connected on the same spi bus. I'm sure _av500_ can relate ;) Turned out that the combined capacitive load was enough to screw up MISO sampling due to the delay introduced. Feb 26 11:41:31 _av500_ certainly has fond memories of the "marvell spi" odyssee :) Feb 26 12:03:03 you're sure this was due to capacitive load and not due to the traces/wires ? Feb 26 12:03:55 the capacitive load of the hdmi framer's pins is really negligible (as you would expect since it has to deal with very high speed signals) Feb 26 12:05:54 QDmitry: have you checked http://processors.wiki.ti.com/index.php/AM335x_U-Boot_User's_Guide ? Feb 26 12:08:19 QDmitry: to be honest, if you have to ask questions like these, maybe using NAND instead of eMMC was not the best choice :) I've had some dealings with raw nand, and I kinda regard it as a mistake to use it in new designs unless you really know what you're doing and have to shave off every last bit of cost for high-volume production Feb 26 12:21:26 and I hope you're using SLC flash, since the MLC flash section on the ubifs homepage still has a lot of issues marked [NEED WORK] (and I have the impression they might remain like that indefinitely since people simply switch to eMMC instead of dealing with headaches like these) Feb 26 12:41:46 zmatt: You are solved my doubts, thank you very much. Feb 26 12:57:00 zmatt: Related to SPI0, I see that this is shared with I2C peripheral and also is connected to EEPROM memory. My question is: Should be not a problem uses thi Feb 26 12:58:22 Shoulb be not a problem use these pins with SPI mode, since it is other protocol and also it will be used when Debian OS has finished its booting process? Feb 26 12:58:44 uhh what? the pins used for spi0 are not normally used for i2c Feb 26 12:59:16 I'm not sure what eeprom you could be referring to... the on-board eeprom is connected to i2c0 which is not accessible on the expansion headers Feb 26 12:59:58 cape identification eeproms may be connected to i2c2 on P9.19-P9.20, which are different pins from those used by spi0 Feb 26 13:00:43 Oh, I see my mistake, this issue is related to beaglbone balck wirelees which use SIP by octavo. Think that the perihpheral connections change there. Feb 26 13:00:46 (it is not mandatory to use these pins for this purpose, although it would require some effort to reconfigure them) Feb 26 13:01:08 nope, all this is identical for the beaglebone black wireless Feb 26 13:01:39 there is no difference between the BBB and BBBW with regard to how the expansion headers are (or can be) used Feb 26 13:01:43 Oh, I am sorry, you are totally right. was a mistkae, I check again and they aare not connected to EEPROM Feb 26 13:02:29 if you want a concise overview of functionality on various expansion header pins, the "P9" and "P8" tabs of my pins spreadsheet may be of use -> https://goo.gl/Jkcg0w Feb 26 13:04:45 Thank you so much for the spreadsheet, it will be helpful for me in the future. Other question. Have ypu ever tried to use this peripheral SPI in PRU in addition with DMA (not binbanding)? Feb 26 13:05:16 I haven't, but it should be no problem Feb 26 13:06:11 using dma from pruss requires a little bit of care to ensure you don't get into a fight with the kernel, but fortunately edma is designed to serve multiple masters Feb 26 13:07:25 there are device tree properties you can use to reserve edma slots (i.e. make sure the kernel driver doesn't use those) Feb 26 13:08:37 anyway, I'm afk Feb 26 13:09:26 Perfect. You are help me a lot. Now I will start my master thesis project :D Feb 26 17:54:40 zmatt: how can you just use .u32 in asm code? is it a predefined type? Feb 26 17:56:07 it's an assembler directive Feb 26 18:01:43 structs in pasm can only contain .u8, .u16, and .u32 directives Feb 26 18:01:47 zmok cool thanks Feb 26 18:01:53 zmatt: ok cool, thanks!* Feb 26 20:32:44 just received my second BBBw after my first one had no WLAN0 MAC Address. When I booted up this new one, logged in as root and typed ifconfig, I get the same issue, no WLAN0. Is there anything I can do or do I need to just keep sending them back until I get one that does not have bad firmware? Thanks... Feb 26 23:43:55 * zmatt . o O ( yes, you could have stuck around for an answer ) Feb 26 23:45:02 in case anyone sees people asking about that problem: beaglebone black wireless + no wlan0 interface == misprogrammed eeprom Feb 26 23:53:31 hey, does anyone know off the top what the pitch is for the BGA eMMC on the BBB? Feb 26 23:53:57 Not I. Feb 26 23:56:06 cnomad: check eMMC spec? Feb 26 23:56:44 Couldn't find the datasheet -- all I found were specsheets, still looking Feb 26 23:57:05 you can download the JEDEC eMMC standard for free Feb 26 23:59:13 oh, I didn't know they all had a standard pitch for eMMCs Feb 27 00:01:00 yes, check JESD84-B51 Feb 27 00:02:10 that one doesn't appear to be free: https://www.jedec.org/document_search?search_api_views_fulltext=jesd84-b51 Feb 27 00:02:26 they are free, you just need to register Feb 27 00:02:49 already logged in -- "Available for purchase: $327.00" -- maybe I'm missing something? Feb 27 00:03:29 uhh, you must be, since I have no special membership (just free registration) and I can access it without any problem Feb 27 00:03:42 https://www.jedec.org/sites/default/files/docs/MO-276E.pdf is probably more relevant to you anyway Feb 27 00:03:52 incognito window? ;) Feb 27 00:03:54 archive.org? Feb 27 00:04:19 this is weird indeed Feb 27 00:05:07 cnomad: if I go to https://www.jedec.org/sites/default/files/docs/JESD84-B51.pdf it just asks for my l/p and then I get the pdf Feb 27 00:05:11 not on icognito, scripts are enbled. anyway, the doc helps, thanks. and if I can assume that all eMMCs have the same pitch, I have another one in hand with datasheet, so everything works out Feb 27 00:05:33 oh, I'm able to dl that... ok Feb 27 00:05:35 :P Feb 27 00:05:37 lol Feb 27 00:05:52 I guess they're trying to ask money for it... but failing badly at it Feb 27 00:06:14 it's "hacking"! Feb 27 00:06:46 this must be a relatively recent development... I've never seen that page asking money for it, it's always been free Feb 27 00:10:35 I don't see any mention about the BGA pitch in 84-B51 Feb 27 00:11:15 yeah I was trying to look for it myself... but that's why I mentioned the MO-276E.pdf may be more useful to you Feb 27 00:11:23 yeah, ty Feb 27 00:12:21 there's a lot of other interesting info in the spec, tho Feb 27 00:12:33 (specifically footprint 1 or 2 of MO-276E) Feb 27 00:12:51 yes, although the eMMC spec is also a horrible mess Feb 27 00:13:06 I hope they're using the money they're now asking to pay an editor :P Feb 27 00:13:23 heh Feb 27 02:15:50 Hi, I am doing some low level work via JTAG on a BBB. I have a Flyswatter2 connected and the latest git openocd. I can connect via JTAG and reset and halt the CPU however after about 5 seconds with nothing happening via JTAG the board seems to reset and boot from the MMC. I would to have the CPU remain halted. Any watchdog or related peice of hardware reseting the board? Feb 27 02:16:21 yup, watchdog Feb 27 02:16:33 CPU or external? Feb 27 02:16:36 cpu Feb 27 02:16:42 Thanks Feb 27 02:16:54 Off to the TRM Feb 27 02:18:31 also keep in mind that halting immediately after reset means some low-level SoC initialization that's normally performed by bootrom won't have happened yet Feb 27 02:19:15 if you're trying to e.g. debug u-boot SPL, it may be better to set a breakpoint in internal RAM instead (where bootrom loads SPL) Feb 27 02:19:26 that will also take care of the watchdog Feb 27 02:19:46 Does the bootrom turn off the watchdog? Feb 27 02:19:48 yes Feb 27 02:19:51 Nice. Feb 27 02:20:57 I am wanting to debug RTEMS applications and so I was going to halt and load the SPL run it and then halt again and the load the RTEMS exe. Feb 27 02:21:27 Is the DDR set up by the SPL or bootrom? Feb 27 02:21:32 SPL Feb 27 02:21:37 Makes sense. Feb 27 02:21:42 bootrom has no way of knowing the ram type and configuration Feb 27 02:21:58 Sure. Feb 27 02:26:35 btw if you want to quickly load a baremetal application onto a beaglebone, I can actually recommend netbooting Feb 27 02:26:47 the SoC can fetch the binary from your computer faster than you can upload it via jtag Feb 27 02:26:53 I want GDB+JTAG Feb 27 02:27:01 you can still debug via jtag Feb 27 02:28:18 Yes. We use netboot when running the RTEMS testsuite and it works really well where we cycle over 500 executables. Feb 27 02:28:32 but uploading code via jtag is pretty slow, and tricky because you'd need to figure out how to interrupt boot at the right time to perform a jtag upload Feb 27 02:29:37 I am looking at that at the moment. I have a stable boot now with your help. Feb 27 02:29:44 Thank you Feb 27 02:29:47 ok **** ENDING LOGGING AT Tue Feb 27 03:00:01 2018