**** BEGIN LOGGING AT Tue Apr 17 03:00:06 2018 Apr 17 04:06:40 Good Day guys Apr 17 04:06:59 I need help to talk to my SPI devices still in u-boot Apr 17 04:07:49 Has anyone initiated SPI in u-boot to sheck if they are present ? Apr 17 09:01:21 Hi Apr 17 09:02:12 Hi Apr 17 09:02:36 lo Apr 17 09:03:23 For BB-BBLK-000-REVC Apr 17 09:03:37 What is its Lifecycle? Apr 17 09:04:07 Can I have an email address of contact person I can ask more questions? Apr 17 09:04:52 Guest75062: all relevant contact information is to be found on beagleboard.org. if you need anything else, contact your distributor. Apr 17 09:07:40 Hi, I am wondering what "tx-num-evt = <1>" in the DT part of the McASP means Apr 17 09:08:15 The documentation says "FIFO levels" Apr 17 09:08:36 yeah that's a fifo threshold for dma, and <1> seems silly low to me Apr 17 09:08:41 I'm using <32> for both tx and rx Apr 17 09:09:03 what does it imply? Apr 17 09:09:10 Makes it things slower? Apr 17 09:09:40 As I am doing realtime signal processing, I want everything as fast as possible, so I am starting at the beginning. Apr 17 09:09:56 higher values slightly increase latency but reduce overhead and reduce the chance of underflow/overflow if dma isn't able to perform the transfer in time Apr 17 09:10:24 Aha, I had problems with under / overflow Apr 17 09:10:50 <32> (which is the max value I think) means 32 words are transferred between memory and the McASP fifos per dma transfer Apr 17 09:11:10 Alrighty! Makes sense now Apr 17 09:11:52 What is the size of a word in a BeagleBone Black? Apr 17 09:13:48 "word" is context-sensitive but typically 32 bits. in this case it means one audio sample Apr 17 09:13:53 (which is 32 bits) Apr 17 09:15:16 Independent of the bitdepth of alsa? Apr 17 09:16:57 yes. McASP has a 32-bit slave interface to the interconnect, so a 16-bit transfer is just a 32-bit transfer with some metadata that says only the lower two bytes are valid (which McASP probably ignores) Apr 17 09:17:45 it doesn't support packing two 16-bit samples into a 32-bit word Apr 17 09:21:02 Thanksss Apr 17 09:30:43 realtime != fast :) Apr 17 09:30:54 realtime == deterministic latency ... Apr 17 09:30:54 indeed Apr 17 09:31:18 -rt versions of the linux kernel are overall slower and less efficient Apr 17 09:32:15 (since they replace most spinlocks by PI-mutexes and turn most interrupt handlers into kernel threads) Apr 17 09:44:19 I need to connect a beckhoff PLC to a beagleboneblack Apr 17 09:45:02 Anyone can help? Apr 17 09:45:49 Ren__: unless you can specify your needs and ask an actual question, i would recommend m3 bolts. i have tested them and can guarantee proper connection. Apr 17 09:46:02 you're more likely to get help if you ask a question that doesn't assume people have datasheets of random other products memorized Apr 17 09:46:11 LetoThe2nd: lol Apr 17 09:46:54 zmatt: no jokin' man! Apr 17 09:52:13 How do i know what os is running on my BBB? Apr 17 09:53:14 Ren__: unless you reflashed it with something custom, it is running Linux, namely a Debian. Apr 17 10:59:56 hello Apr 17 11:00:13 could everyone help me with some information Apr 17 11:00:14 ? Apr 17 11:00:29 it's abou beaglebone black system Apr 17 11:01:02 I use the information for 3D models and all data from elinux.org Apr 17 11:01:43 are all the data wright there? Apr 17 12:10:50 jkridner[m]: lol, did I make a typo or did you make one? fortunately in norway they figured out it was supposed to be NL rather than NO Apr 17 13:30:25 BBB Stretch IoT from 2018-03-05. Trying to access serial port at /dev/ttyO2. The /dev directory lists only ttyO0. /dev/ttyS{1-5} exist. I have discarded the old eMMC bootloader with `blkdiscard /dev/mmcblk1`. I am using a standard image across serveral BBBs, I discard the old bootloader with the given command if needed. I was able to read/write to the serial port yesterday, today (same image & process, different BBB) I cannot because t Apr 17 13:30:33 Any idea what my error(s) are? Apr 17 13:56:09 that message cuts of at "I cannot because t" Apr 17 14:01:59 * I cannot because the /dev/ttyO2 doesn't exist. Apr 17 14:04:19 blanks: ttyO* devices are deprecated and replaced by ttyS* Apr 17 14:04:35 ttyO0 is presumably a symlink to ttyS0 Apr 17 14:05:23 backwards compatibility symlinks for the other ttyS* devices should be created as well though, no idea why that wouldn't work for you Apr 17 14:06:21 or rather, why it apparently works inconsistently for you Apr 17 14:06:26 Yes it is a symbolic link to ttyS0. When trying to write to /dev/ttyS2 I get an input/output error. Apr 17 14:06:33 yes it is odd. Apr 17 14:10:23 can you try: { echo $(cat /proc/device-tree$(cat /proc/device-tree/aliases/serial2)/status); } 2>/dev/null Apr 17 14:12:14 it prints "disabled" to the standard output. Apr 17 14:12:28 well that at least explains why you can't use ttyS2 Apr 17 14:12:49 haha yeah Apr 17 14:13:25 can you pastebin the contents of your /boot/uEnv.txt ? Apr 17 14:13:33 yes Apr 17 14:13:37 is there a CAPE attached to the BBB ? Apr 17 14:16:24 https://pastebin.com/jguyUE6P is the pastebin to my /boot/uEnv.txt Apr 17 14:17:04 I do not know if there is a CAPE attached. I've seen capemgr before in files, so I assume that is software and not hardware. Apr 17 14:17:16 no a CAPE is a piece of hardware Apr 17 14:17:30 that attaches to the expansion connectors Apr 17 14:17:59 No, if it is not installed by default on the BBB, I do not have it. Apr 17 14:18:02 (specifically, a cape is any piece of hardware that attaches to it and has a cape identification eeprom) Apr 17 14:18:06 ok Apr 17 14:18:45 you're booting from sd card? Apr 17 14:19:16 yeah you must be since you said you erased eMMC Apr 17 14:19:18 ehm Apr 17 14:19:23 correct. I have used `blkdiscard /dev/mmcblk1` Apr 17 14:19:40 sudo blkdiscard I presume Apr 17 14:19:43 yes Apr 17 14:20:15 ehm, then I'm kinda puzzled since I don't see any reason for the uarts to be disabled Apr 17 14:21:10 can you check the board identification eeprom with: head -c 16 /sys/bus/nvmem/devices/0-00500/nvmem | hexdump -C Apr 17 14:21:49 stdout from command: """00000000 aa 55 33 ee 41 33 33 35 42 4e 4c 54 30 30 43 30 |.U3.A335BNLT00C0| 00000010""" Apr 17 14:22:00 ok so that's fine too Apr 17 14:22:03 ehmmmmm Apr 17 14:22:31 * zmatt sprouts some questionmarks from his forehead Apr 17 14:22:58 lol Apr 17 14:23:55 eMMC is erased, board id is fine, there's no physical cape attached, there's no overlay being manually loaded using uEnv.txt, enable_uboot_overlays and enable_uboot_cape_universal are both set Apr 17 14:25:11 so my conclusion would be: cape-universal ought to be loaded Apr 17 14:25:45 (yeah okay, the name of "cape-universal" probably doesn't help with confusion around the name "cape", since it... obviously isn't a cape) Apr 17 14:26:56 my suggestion would be to check u-boot's messages on the serial console Apr 17 14:27:06 oof Apr 17 14:27:14 haven't used that before Apr 17 14:29:49 you need an usb-serial converter like one of these: https://elinux.org/Beagleboard:BeagleBone_Black_Serial or with a bit of care you could use another beaglebone (where the uarts *are* working) as client, just make sure it is powered before the beaglebone whose console you're monitoring is powered up Apr 17 14:30:50 Alright thanks for the advice! I'll look into it. Apr 17 14:43:05 huh, according to the part number there's an AM5729BABCXEA on my x15.... which is interesting, since the AM5729 doesn't exist according to the TI website Apr 17 21:01:23 Trying to download drivers for windows 10 64 bit. Installer opens but all files fail to install. Apr 17 21:23:07 the error is: you were too impatient to wait for a reply **** ENDING LOGGING AT Wed Apr 18 03:00:03 2018