**** BEGIN LOGGING AT Sat Sep 21 03:00:00 2019 Sep 21 03:49:26 zmatt.... yeah, that should be tied to p9_07, not p9_05. Sep 21 03:49:50 document says p9_03. Sep 21 03:50:07 which would be 3.3V Sep 21 03:50:47 hmmmm..... 3.3V probably makes sense. Sep 21 03:51:09 * jkridner[m] looks at https://www.adafruit.com/product/980 Sep 21 03:51:48 2.5V-5.5V input. Sep 21 03:52:10 so, should be using the 3.3V output from BeagleBone Black, per the text.... Sep 21 03:52:13 drawing is just wrong. Sep 21 03:53:59 https://github.com/beagleboard/cloud9-examples/issues/15 Sep 21 03:54:32 working on obsoleting all of the stuff on the website and moving it to the board. Sep 21 03:55:19 * jkridner[m] might need to break out Fritzing after a couple of years. Sep 21 04:52:24 jkridner[m]: yeah it should use 3.3v... in general any schematic where 5v is used should probably be scrutinized Sep 21 05:10:37 indeed Sep 21 06:27:43 /cl **** BEGIN LOGGING AT Sat Sep 21 11:26:09 2019 Sep 21 16:03:19 Hi all, please help me. I bought beagleboard x15, for start I downloaded linux debian from beagleboard website(Debian 9.5 2018-10-07 ). It`s work fine, but I would like using SPI inteface and I dont know how to edit device tree or how to use it. I have experiences with beaglebone black with overlays but in beagleboard is dosnt work. Please help Sep 21 16:03:20 thanks Sep 21 16:03:42 lorant: yeah stuff like that is a giant headache on the am572x Sep 21 16:05:15 part of the problem is that officially TI expects you to do pin configuration by using their tool, sticking its output into u-boot and recompiling it to ensure pinmux and iodelay is applied during very early platform initialization (in u-boot SPL) Sep 21 16:06:16 the reason is hardware errata: changing pinmux or iodelay at runtime can cause the I/O cell to glitch for (iirc) several nanoseconds Sep 21 16:07:04 which doing it in u-boot SPL avoids since it enters I/O isolation mode (during which all I/O is forced high-impedance) Sep 21 16:08:40 changing iodelay has another headache that if there's simultaneous access (by another initiator) to another peripheral on the same interconnect, a system lockup occurs Sep 21 16:09:18 in some cases these don't matter though, correct iodelay isn't always necessary and glitches may be tolerable depending on the pin usage Sep 21 16:11:03 here's my suggestion: first check what the current pin configuration is. last time I checked u-boot actually sets up the expansion header pins in a way that's intended for a specific expansion board. maybe there's already SPI there Sep 21 16:11:48 you can use e.g. my show-pins utility: https://github.com/mvduin/bbb-pin-utils/tree/bbx15-experimental#show-pins Sep 21 16:16:17 Hi zmatt :) thank you, I little better understood the problem. but I dont know how to set up another dtb because in uEnv.txt, i dont have defined any. I dont know how to modify device tree for SPI pinout. Sep 21 16:16:18 pinconfig. Sep 21 16:18:22 if spi pins are already configured then all you need to do in DT is enable the spi controll and add your spi device to it. if there aren't any pins configured for it yet, then you'd need to configure those as well. in that case you should consider replacing u-boot by one that leaves all pins unconfigured so you don't have issues with pins being configured wrong during early boot. I have an u-boot ... Sep 21 16:18:28 ...built like that I can dig up for you Sep 21 16:18:45 yeah making a custom DT isn't hard fortunately, hold on Sep 21 16:20:26 ah I even have an spi example Sep 21 16:24:25 so, grab the dtb-rebuilder repository branch corresponding to the kernel series you're using, e.g.: git clone -b 4.14-ti https://github.com/RobertCNelson/dtb-rebuilder Sep 21 16:25:42 in there, save https://pastebin.com/raw/C2vrXtQf as src/arm/am57xx-beagle-x15-custom.dts and do "make src/arm/am57xx-beagle-x15-custom.dtb" Sep 21 16:25:58 sudo cp src/arm/am57xx-beagle-x15-custom.dtb /boot/dtbs/ Sep 21 16:26:18 then configure dtb=am57xx-beagle-x15-custom.dtb in /boot/uEnv.txt Sep 21 16:30:04 if you can find pins already configured to spi mode then you can omit the pinctrl-* properties of the mcspi node (lines 12-13) and the entire pinmux block (lines 24-34), but be sure to use the correct mcspi instance and chip select (the 1 in 'spidev@1' and "reg = <1>;'). if using my show-pins utility to check which mcspi instance, beware that it uses zero-based indexing while DT uses 1-based ... Sep 21 16:30:10 ...indexing for mcspi instances Sep 21 16:31:29 sorry zmatt .. I have poor wifi connection , please send me again links because everything is missing Sep 21 16:35:56 and if you want an u-boot build that leaves the expansion header pins unconfigured (to save having to build one yourself), I've put it here: https://liktaanjeneus.nl/bbx15/ Sep 21 16:36:02 I'll save a chat transcript for you, one sec Sep 21 16:37:05 https://pastebin.com/KMx166AG here ya go Sep 21 16:37:19 very nice of you , thanks :) Sep 21 16:47:42 I tried your util for showing pins, but unfortunately every spi1 pins is setted up as gpio :/ Sep 21 16:48:40 https://pastebin.com/LpQ6swFD Sep 21 16:49:14 script is very usefull ;) Sep 21 16:53:12 then you'll have to just configure the pins in DT like my example does :) a glitch probably won't matter for spi, but for safety you could add a series resistor to the miso output of your slave device(s) to limit current if a drive conflict does briefly happen Sep 21 16:56:04 and I recommend replacing your u-boot (I've included an install script with my u-boot build) to leave the pins unconfigured by u-boot, although it seems the pins my example uses are configured as mmc pins by u-boot, which is probably benign (those will all be high-impedance with internal pull-up) Sep 21 16:57:52 hmm I wonder how much work it would be to make u-boot scan the DT for pinmux/iodelay to use and then temporarily reenter I/O isolation to apply that pinmux/iodelay Sep 21 17:03:21 Woulldnt it be better to use linux form TI SDK (Yocto)? but i dont know it neighter how to set up :D Sep 21 17:04:08 "better" is subjective Sep 21 17:07:09 debian is likely to be a more comfortable environment than yocto, you can easily just install packages and such... I don't know much about yocto, I think it might have some optional support for packages (though dunno if there's any ready-to-go repository compatible with it) but afaik you generally need to rebuild/reflash the whole system to make changes Sep 21 17:07:27 but obviously there are benefits to doing the latter Sep 21 17:10:43 regardless, the TI SDK is not supported here in this channel, you'd need to go to TI's support forums (e2e.ti.com) for help Sep 21 17:18:11 yes, I think so too. I would try to configure in DT, thank you very much for help zmatt. Sep 21 17:18:37 you'd have to deal with this stuff regardless of whether you use debian or yocto anyway Sep 21 17:19:31 debian on beaglebone just made it a bit easier with overlays and cape-universal, and unfortunately nothing equivalent to that has reached the bbx15 yet Sep 21 19:53:28 Hi. Sep 21 19:53:44 How do I know that flashing is in progress? Sep 21 19:53:58 I have successfully booted from microSD Sep 21 19:54:17 I can ssh to BBGW Sep 21 19:54:26 then it's not a flasher image, hence won't flash eMMC Sep 21 19:54:39 though you can make a one-line change to /boot/uEnv.txt to turn it into a flasher image Sep 21 19:55:09 I made the one line change on the existing file on eMMC Sep 21 19:55:37 that's a bad idea Sep 21 19:55:56 since that means that when you try to boot from eMMC, it will try to flash eMMC to eMMC... which is not a recipe for success Sep 21 19:56:20 Yes, it is not booting without microSD anymore Sep 21 19:56:24 exactly that Sep 21 19:56:36 you need to make the change on the sd card. Sep 21 19:57:34 when it's flashing there's a distinctive back-and-forth led pattern (0 1 2 3 2 1 0 1 2 3 2 1 0 etc) Sep 21 19:57:54 (and you can't ssh to the beaglebone in that state) Sep 21 19:58:01 aha, good to know Sep 21 19:58:20 Can I access the microSD from the running system Sep 21 19:58:24 if it fails then all leds will flash simultaneously. if it succeeds then I think all leds will be solid on for a bit and then it'll power itself off Sep 21 19:58:38 uhh the running system *is* microSD Sep 21 19:58:44 so the file is just /boot/uEnv.txt Sep 21 19:58:51 ahh, yes Sep 21 19:59:24 after flashing is done and it turns itself off, don't forget to remove the sd card before turning it back on Sep 21 19:59:33 ok Sep 21 19:59:52 (otherwise it would reflash again) Sep 21 20:00:15 Reflashing again doesnt do harm, right? Just takes more time. Sep 21 20:01:38 yup it's mostly just a waste of time Sep 21 20:02:22 I appears that this newer image is asking for root password Sep 21 20:02:44 and eMMC (like any form of flash storage) does slowly wear out whenever data is written to it, although reflashing occasionally isn't really going to make an impact on that Sep 21 20:03:38 it's been like for that many many years. there's normally no reason to log in as root, and openssh-server in its default configuration disallows root login using password authentication (it requires e.g. public-key authentication) Sep 21 20:04:16 the debian account has sufficient privileges for most things, and for the rare occasion you need root privileges (using apt, editing system config files) you can use sudo Sep 21 20:05:35 I thought I needed to be root to change uEnv.txt but yes, appreantly not. Sep 21 20:05:48 you do, but that's what sudo is for Sep 21 20:06:49 I was able to change it being user debian Sep 21 20:09:25 really? odd Sep 21 20:10:36 I am seeing a knight-rider sequence now :) Sep 21 20:19:31 ..and it's working again. Thanks @zmatt ! Sep 21 20:19:56 :) Sep 21 21:11:38 oh hey TI changed the adc specs in revision K of the datasheet... they added ADC clock frequency 3 MHz (max) and changed Sampling rate 200 kSPS from (typ) to (max) Sep 21 23:30:13 lol, the tps65216 has a "buck-boost" with specified input 3.6-5.5V and output 1.175-3.3V **** ENDING LOGGING AT Sun Sep 22 03:00:26 2019