**** BEGIN LOGGING AT Wed Apr 03 02:59:57 2019 Apr 03 10:45:05 AM3358 from Sitara Family of TI and the Beaglebone linux version? Apr 03 11:02:40 what ? Apr 03 11:33:42 that was an interesting word salad **** BEGIN LOGGING AT Wed Apr 03 14:09:24 2019 Apr 03 16:32:59 Hello Apr 03 16:33:32 which touch screen do you suggest to work with beaglebone black? Apr 03 16:33:44 any one has suggestion? Apr 03 16:34:09 any with cap-touch.. Apr 03 16:36:57 zmatt any thoughts on extending your /dev/pwm udev rule to do something similar for spidev, as mainline changed the node name around the v4.14.x era Apr 03 16:38:17 i've got two groups asking for a stable interface, for /dev/spidevX.Y and i think doing it in udev like you did with the pwm, might be a better solution, then mainline can keep breaking things on their own time.. Apr 03 16:39:29 rcn-ee[m]: I use https://github.com/mvduin/py-uio/blob/master/etc/udev/rules.d/10-of-symlink.rules so I can add a 'symlink' property to device nodes in DT Apr 03 16:40:06 works for a variety of devices, including spi Apr 03 16:40:24 and custom overlays can choose to use custom names Apr 03 16:40:58 nice, do you mind if i add that udev rule to our bb-customizaiton package? Apr 03 16:41:33 yes, I think adding such a convenient udev rule would make you a terrible person! ;P Apr 03 16:43:26 so, if you add that rule, you can then in DT add a property like symlink = "spi/0.0"; for &spi0 cs0, or something similar Apr 03 16:43:39 to create a /dev/spi/0.0 symlink Apr 03 18:35:35 I use the command "iw dev mesh0 set channel 1 HT20" and the result of command "iw dev mesh0 info" is "channel 1 (2412 MHz), width: 20 MHz, center1: 2412 MHz". When I use the command "iw dev mesh0 set channel 11 HT20", the command "iw dev mesh0 info" doesn't show the channel info. The wireless device doestn't support the channel 11? Apr 03 18:35:43 how can help me? Apr 03 18:44:07 hello Apr 03 18:44:17 i am setting up my beaglebone black Apr 03 18:44:54 i follow the instruction Apr 03 18:44:59 i am at step0#F Apr 03 18:45:40 try boot the board off of the SD card Apr 03 18:46:18 since the beginning, the first LED light is blinking and the third one is steady on Apr 03 18:46:29 the second one and the third one, no response Apr 03 18:46:35 it is more than 1 hour, Apr 03 18:47:01 do you know if the flash image is sucessful or not Apr 03 18:47:11 the LED lights are not steady off or on at all Apr 03 18:47:37 Stretch LXQT (with graphical desktop) for BeagleBone via microSD card Debian 9.5 2018-10-07 4GB SD LXQT Apr 03 18:47:47 this is the image i download and write in to the SD card Apr 03 18:47:56 can someone help Apr 03 18:47:56 Guest62207: did you follow the steps for flashing the image to eMMC? it sounds like you simply booted from sd card Apr 03 18:48:03 It'll shutdown in < 20 minutes if successful Apr 03 18:48:21 btw, for most purposes the stretch-iot image is recommended over the stretch-lxqt image, especially if you flash it to eMMC Apr 03 18:48:47 Insert SD card into your (powered-down) board, hold down the USER/BOOT button (if using Black) and apply power, either by the USB cable or 5V adapter. If using an original BeagleBone or PocketBeagle, you are done. If using BeagleBone Black and desire to write the image to your on-board eMMC, you'll need to follow the instructions at http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Flashing_eMMC. When the flashing is complete Apr 03 18:48:49 the lxqt image doesn't leave much free space, and having a desktop environment on the beaglebone is rarely useful Apr 03 18:49:12 i am at the step #0F Apr 03 18:49:14 Guest62207: please don't copy-paste large chunks from the site. we know what it says there Apr 03 18:49:27 ok, sorry Apr 03 18:49:50 yes, i simply booted from SD card Apr 03 18:49:52 Guest62207: like I said, your description sounds like you've successfully booted from sd card Apr 03 18:50:04 do i need flash the image to emmc? Apr 03 18:50:18 i saw the link, but don't know where to type the command Apr 03 18:50:43 no Apr 03 18:51:16 i said, since the beginning of the step#0F, the first LED is blinking, the third is steady on, and the second the fourth is steady off Apr 03 18:51:18 whether to boot from sd card or flash the image to eMMC is entirely up to you. If you choose to continue working from sd card however, I strongly recommend erasing eMMC using "sudo blkdiscard /dev/mmcblk1" to avoid problems Apr 03 18:51:28 it is like this since the beginning, already more than 1 hour Apr 03 18:51:49 you don't need to repeat yourself, I understood you the first time Apr 03 18:51:53 so login into it.. ssh or serial Apr 03 18:52:16 where is the website to login Apr 03 18:52:45 you'll probably want to use an ssh client Apr 03 18:53:11 sorry i am very new to bb and i am learning from beginning, please bear with me Apr 03 18:53:27 note also again that the stretch-iot image is recommended for most users, not the stretch-lxqt image Apr 03 18:53:53 i still don't know what to do Apr 03 18:53:58 Guest62207: then get a book: https://www.amazon.com/Exploring-BeagleBone-Techniques-Building-Embedded/dp/1119533163/ref=sr_1_3?keywords=beaglebone&qid=1554317611&s=gateway&sr=8-3 Apr 03 18:54:34 Guest62207: you may be interested in the stretch-iot flasher image provided by strawson. if you boot from that, it will automatically proceed to flash eMMC: http://strawsondesign.com/docs/images/BBB-blank-debian-9.5-iot-armhf-2018-10-07-4gb.img.xz Apr 03 18:54:58 that minimizes the possibility for making errors Apr 03 18:55:10 but i did use the SD card Apr 03 18:55:18 it looks like it is not sucessful Apr 03 18:55:31 Guest62207: you booted from a standalone image, not a flasher Apr 03 18:55:57 why Apr 03 18:56:54 rcn-ee[m]: this really sucks btw, basically everyone has to dive into the commandline to either turn the standalone image into a flasher, or erase eMMC to avoid the risk of a broken system due to an old u-boot on eMMC (probably the #1 cause of problems I see) Apr 03 18:58:00 i open the link you sent, need to pay to buy the tool Apr 03 18:58:05 what? Apr 03 18:58:13 what are you talking about? Apr 03 18:58:21 the first link Apr 03 18:58:27 it is link to Amazon Apr 03 18:59:06 oh rcn-ee[m]'s link to a book. he suggested that because you seem to be very confused despite the instructions available Apr 03 18:59:39 but I agree, the process is more confusing right now that it needs to be Apr 03 19:00:37 I suggest you just download the image I linked to, flash that to sd card and boot from it. it should automatically proceed to reflash eMMC Apr 03 19:00:55 ok, Apr 03 19:01:09 so the old image file will be erased autoamtically in the SD card? Apr 03 19:01:47 when you flash an image file to sd card (e.g. using etcher), this always erases any previous contents of the sd card in the process Apr 03 19:02:24 ok, thanks for clarification Apr 03 19:02:41 so now i reload the image file to the sd card and then flash to the bbb, right? Apr 03 19:02:44 matching "flasher" images located here: https://rcn-ee.net/rootfs/bb.org/testing/2018-10-07/ but jasonk doesn't want to directly document them on beagleboard.org/latest as users get confused with teh other situation... why doesn't this flasher not work on my microsd, it shuts down after 10 mins.. Apr 03 19:03:11 likewise, if you boot the beaglebone from a flasher-card (which is what you'll create by flashing the image file I linked to to sd card), the previous contents of eMMC will be lost in the process Apr 03 19:03:28 ok Apr 03 19:03:32 i am trying now Apr 03 19:04:06 rcn-ee[m]: well users are definitely getting plenty confused right now Apr 03 19:05:21 do i need to type Apr 03 19:05:22 ##enable BBB: eMMC Flasher: cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh Apr 03 19:05:24 rcn-ee[m]: there should just be a simple page with some javascript to let people select their device and (when applicable) whether they want to run from sd card or flash to eMMC, and then download the right file Apr 03 19:05:44 Guest62207: you can ignore that part, it's taken care of with the image I gave you Apr 03 19:06:59 rcn-ee[m]: in most cases, for devices with eMMC, reflashing is what people should typically do, and right now it's made unnecessarily complicated for newbies Apr 03 19:08:10 rcn-ee[m]: this is further aggrevated by the fact that if they don't flash to eMMC, there's a good chance (depending on the age of whatever's on eMMC) that they'll have a broken system that only superficially appears to work Apr 03 19:08:40 ok, got you, thanks Apr 03 19:10:02 rcn-ee[m]: not long ago someone came here who had been trying to get a cape to work for two weeks, having asked for help on E2E, tried all sorts of crazy stuff including hacking stuff into the main dts, and then he luckily came here and, as I expected, a simple "sudo blkdiscard /dev/mmcblk1" fixed all his problems Apr 03 19:10:10 so it takes about 45 minutes, right? Apr 03 19:10:24 <20minutes Apr 03 19:10:28 Guest62207: I don't think it takes that long at all Apr 03 19:10:50 ok, Apr 03 19:10:50 it was 45 minutes 10 years ago with angstrom's flasher.. lots of old directions state that number.. Apr 03 19:11:03 the four lights are blinking one by one at at time Apr 03 19:11:15 rcn-ee[m]: the current getting-started guide still says that number :P Apr 03 19:11:16 cyclon Apr 03 19:11:17 i see. thanks Apr 03 19:11:21 Guest62207: that means it's flashing Apr 03 19:11:29 ok, thanks Apr 03 19:11:47 oh god, we do? Apr 03 19:14:54 underpromising makes it possible to overdeliver! Apr 03 19:20:02 where can i find a srm for the bone green wireless and black wireless? where can I find the differences between theese boards and the bone black Apr 03 19:20:20 JGalt: my advice: avoid the green-wireless Apr 03 19:20:53 it pointlessly sacrifices a whole bunch of expansion header pins for its wifi/bluetooth functionality, and is therefore also incompatible with a variety of capes Apr 03 19:21:04 curious why? is it not simply a black minus the hdmi parts? Apr 03 19:21:24 ah Apr 03 19:21:26 the black-wireless simply reused the pins that the black uses for ethernet, and is 100% compatible with the black w.r.t. the expansion headers Apr 03 19:21:39 the green-wireless left those pins unused, and sacrifices expansion header pins instead Apr 03 19:21:50 does the black wireless make the same sacrifice? Apr 03 19:22:01 I just answered that Apr 03 19:22:36 ah sorry, messages crossed in the ether Apr 03 19:24:04 0.7 seconds ping time from me to you... not really awful, but not great either Apr 03 19:25:14 any idea where or how one might find or obtain a black that does not have hdmi, thus leaving the pins for that usable for other things? Apr 03 19:25:25 you can disable hdmi and reuse the pins Apr 03 19:25:39 there's a flag for that in /boot/uEnv.txt Apr 03 19:26:06 (this also happens automatically when you attach a cape that needs those pins) Apr 03 19:26:50 ah, ok things have come along as ive been away for a while Apr 03 19:27:10 disabling hdmi has always been an option Apr 03 19:27:30 though the settings nowadays are nicer than they used to be Apr 03 19:28:09 if you want to you can even disable eMMC (and boot from sd card) to free up those pins as well Apr 03 19:28:59 so pretty much its up to the cape builder to specify the needed pinmux in the eprom ans as long as thats done it ought just work? Apr 03 19:29:40 not quite, the cape eeprom just gives an identification string and u-boot loads the overlay for it (based on the name and version in eeprom) Apr 03 19:30:52 so what if uboot does not know about my uber custom cape that only one exists in the world? Apr 03 19:30:52 disabling hdmi is currently still done based on a hardcoded list of capes known to conflict with it, so in case of a custom cape you'd have to add it to that or manually disable hdmi. (ideally u-boot would auto-detect whether an overlay is compatible with hdmi or not, but we're not there yet) Apr 03 19:32:03 ah, ok. might a flag or something be settable in uboot? Apr 03 19:32:24 what do you mean? Apr 03 19:32:37 u-boot takes its settings from the /boot/uEnv.txt config file Apr 03 19:32:59 something in the uboot config like disable_hdmi=yes Apr 03 19:33:24 yes, that's what I mentioned right from the beginning... 21:25 < zmatt> there's a flag for that in /boot/uEnv.txt Apr 03 19:33:45 disable_uboot_overlay_video=1 Apr 03 19:33:57 (there's also 21:25 < zmatt> there's a flag for that in /boot/uEnv.txt Apr 03 19:34:00 whoops Apr 03 19:34:05 (there's also disable_uboot_overlay_audio=1 Apr 03 19:34:16 in case you just want to disable hdmi audio, but not hdmi entirely) Apr 03 19:34:31 ugh, copy-pasting is hazardous... I made a mess Apr 03 19:34:48 i get the idea Apr 03 19:38:11 so if one disables the hdmi and emmc on the black are we then pretty much back to the same pin availibility and bunctionality of the "std" beaglebone? Apr 03 19:40:02 pretty much yeah. there are still some differences though, the old beaglebone white had an older (and slower) revision of the am335x SoC, 256 MB DDR2 ram instead of 512 MB DDR3L ram Apr 03 19:40:21 JGalt if you go to production and sell the video/cape etc.. just ping us and it'll be updated into the feed: https://github.com/RobertCNelson/Bootloader-Builder/blob/master/patches/v2018.09/am335x_evm/0002/board/ti/am335x/board.c#L332-L406 Apr 03 19:41:25 the white also has integrated jtag debugger and usb-serial interface Apr 03 19:41:53 and a header for the pmic Apr 03 19:42:28 hmm, what was on it? Apr 03 19:43:55 it was 2x6 female header, it made capes even more hard to remove.. looking up srm again. Apr 03 19:44:08 lol Apr 03 19:44:48 ahh, battery and backlight Apr 03 19:45:39 @rcn-ee thinking of doing a couple capes actually.... one a simple breakout, though that's been done in various ways, and another for to provide some interfaces for a beagle running asterisk, and maybe yet another targeted toward the ahrs crowd. Apr 03 19:45:46 well the battery pins are still there (although not really safe to use unless you patch the beaglebone... but the white suffered from that problem too) Apr 03 19:47:55 we keep getting better silicon thrown our way for gyro, mag, accel, pressure, & temp sensors. Apr 03 19:50:07 always nice getting silicon thrown at you (unless it's at high velocity) Apr 03 19:52:13 well the companies keep making gradual improvements in accuracy and speed of their chips so much so that its sometime hard for those building capes to keep up. Apr 03 19:53:12 it's not always necessary to have the latest incremental improvement at any given time. typically good enough is good enough Apr 03 19:54:37 in a related thought.... the mcasp port on the beagle.... how many 8 bit audio channels can it handle? how many channels can the beagle itself reasonably handle? Apr 03 19:55:28 i understand that port can be used as i2s OR tdm Apr 03 19:55:54 ...with tdm allowing more channels Apr 03 19:56:16 the linux kernel is the main limiting factor. the hardware itself supports up to 32 channels per data line Apr 03 19:56:59 https://pastebin.com/raw/37Vr51Wr Apr 03 19:58:02 with two mcasp instances, each having 4 data lines, and 32 channels per data line, the beaglebone supports up to 256 channels in total, from a hardware point of view Apr 03 19:59:11 (there's also a maximum on the bit clock frequency... iirc either 25 MHz or 50 MHz, but with only 8 bits per channel that's not a problem) Apr 03 19:59:47 wait no, mcasp 1 only has two data pins accessible Apr 03 20:00:07 so 192 channels then Apr 03 20:01:50 iirc you'll run into software limitations way before then though.. I think linux doesn't support more than 32 channels on a single audio device Apr 03 20:04:44 so one of those ports needs to be audio in channels and one audio out channels or can in and out be combined on one device? Apr 03 20:04:59 each data pin can be independently configured to be input or output Apr 03 20:06:20 nice, now the fun of finding devices Apr 03 20:09:38 if you intend to use more than 8 channels per pin or more than 16 channels per mcasp, you may also want to verify that linux supports that before committing to a design that requires it Apr 03 20:10:19 I don't really remember specific limits, I do remember having found out that there are limits Apr 03 20:11:25 zmatt: I just found that Jargon File! Apr 03 20:11:34 PEBKAC! Apr 03 20:11:35 Hhahahahaha. Apr 03 20:12:50 acronyms! Apr 03 20:25:50 Hhahahahaha = ROTFL Apr 03 20:28:21 I found the glossary. You people are in for some fun! Apr 03 20:28:33 But. Up, up, and away! Apr 03 20:32:39 4-8 ports ought be enough.... but it would be nice to have the ability to load the bone to the point it started being unable to process that much audio Apr 03 20:33:21 well that obviously depends entirely on what sort of processing and how well optimized it is Apr 03 20:34:27 er not ports.... not even really channels... more thinking streams Apr 03 20:35:41 yeah you mentioned asterisk, which also explains why you'd consider 8-bit to be okay Apr 03 20:35:44 basicly in an app such as asterisk, a channel is a pair of bitstreams - one in, one out Apr 03 20:36:33 basicly looking to do toll quality voice Apr 03 20:37:07 though with radio hardware, specificly app_rpt Apr 04 01:13:50 What happens when shows a bunch of pins but the uart4_rxd needs to be set and is not default? Apr 04 01:14:00 Oh...this is on the BBBlue? Apr 04 01:15:10 Should I just set it up: ? Apr 04 01:15:15 I can try it. What the hell? Apr 04 01:30:08 Off to test! Apr 04 01:40:57 set_: as long as your electrical periphery is fairly sane, one of the best methods of learning is by try/fail... Apr 04 01:42:53 Understood. Apr 04 01:46:05 trial and error brought me to make things work w/ ./waf and python3 w/ a particular image. Apr 04 01:46:34 BBBlue and ardupilot stuff... Apr 04 01:47:07 Yep. **** ENDING LOGGING AT Thu Apr 04 02:59:57 2019