**** BEGIN LOGGING AT Thu Oct 01 02:59:57 2020 Oct 01 04:13:07 Is bbb running mainline kernel? Oct 01 04:15:41 there are -bone kernel series and -ti kernel series available, which are mainline + patches and TI kernel + patches respectively. the default used to be -bone, though it has been -ti for a while now Oct 01 04:18:22 TI actively tries to get their stuff upstream though so I'd expect these to converge eventually Oct 01 04:25:58 I am using a Beaglebone AI and would like to use UART6 on the cape headers (P8.37 & P8.38). I created a device tree overlay to set the correct mux mode on these pins and disable the pins used by the Bluetooth module. UART6 seems to be enabled and appears as /dev/ttyS5. I can open /dev/ttyS5 but it never retruns any data (I can see the data on my Oct 01 04:25:59 scope, so I know it should have something). fuser -av /dev/ttyS5 does not show any other process using the device file, is there something else I need to do to take this uart away from the Bluetooth device? Oct 01 04:27:42 hmm Oct 01 04:31:34 this is odd... I'm not seeing any definitions in the .dts for bluetooth other than &uart6 { status="okay"; }; ... am I blind or is bluetooth non-functional on the AI currently? Oct 01 04:34:58 or is the hci_uart driver being attached to the uart at runtime by some startup script? since that would presumably mess with using the uart for other purposes Oct 01 04:37:00 that's the only thing I can think of. otherwise, if the port is not being used by bluetooth, then changing the bluetooth pins (which are setup by u-boot) to safe mode and changing P8.37/38 to uart mode should definitely suffice Oct 01 04:37:50 hci_uart does not seem to be loaded, is that usually a kernel module? Oct 01 04:38:10 I don't see a process by that name either. Oct 01 04:38:22 no idea if it's compiled as module or built in, check kernel config I guess Oct 01 04:38:37 I haven't really worked with bluetooth and don't know much about it Oct 01 04:40:14 Yes, it is a module, I found it in the config. Thanks for your help, I'll keep poking at it. Oct 01 04:40:24 yeah, then dunno Oct 01 04:40:27 double-check pinmux Oct 01 04:41:33 you can e.g. use my https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins ... it should show the bluetooth pins if you pass -v I think. note that it will call the uart "uart 5" (just like linux calls it ttyS5) Oct 01 04:47:52 Oh, that's a nice tool. It shows the values I expect, the cape pins are assigned to uart 5. Oct 01 04:48:27 also make sure no other pins are (i.e. "show-pins -vv | grep 'uart 5'") Oct 01 04:53:14 and disable any startup services that sound like they're bluetooth-related Oct 01 04:58:34 Oh, there are some bluetooth sounding things running, let me figure out how to kill those. Oct 01 05:03:14 And I was so busy looking for hci modules, I missed the 'bluetooth' module, lots more to clean up! Oct 01 05:29:33 well the thing to track down is why that module gets loaded Oct 01 05:29:40 which is probably a startup service Oct 01 05:37:02 at minimum you can systemctl disable bluetooth.service and bb-wl18xx-bluetooth.service, but it doesn't look like either of those is responsible Oct 01 05:40:53 (but it doesn't hurt to try of course, see if disabling those and rebooting helps) Oct 01 06:13:14 OK, still haven't managed to keep bluetooth from starting on boot, but getting closer. It seems to be managed by both sysv init and something about alsa is starting it up, I'm still trying to figure that out. Oct 01 06:15:33 I did manage to crash show-pins, I now have a line in /etc/interrupts that looks like "46: 3 0 CBAR 101 Level", changing line 152 of show-pins to "/\G(?:\d+\s+)+(\S+)\s+(\d+)\s+\w+(?:\s+(\S+))?/gc or die;" so it can handle the missing consumer fixes it. Oct 01 06:15:41 sorry /proc/interrupts Oct 01 06:32:17 Thanks again for the help, I'm going to call it a night and try again tomorrow. Oct 01 08:12:01 pretty sure "systemctl disable bluetooth" should suffice.. I wonder what he did :P Oct 01 10:06:11 HI Oct 01 10:09:16 hi Oct 01 10:12:17 Hi Oct 01 10:12:23 I am looking for 20 BeagleBoard X15. Oct 01 10:13:06 I am from India. Oct 01 10:13:13 I was to get Best Price. Oct 01 10:13:28 Are you the best person to discuss? Oct 01 10:14:40 hi Micheal Oct 01 10:14:53 hi Oct 01 10:14:59 hi Michael - mouser have them in stock Oct 01 10:15:13 19,250.10 Oct 01 10:15:52 per piece 19250.10 Rupees Oct 01 10:16:16 yeap Oct 01 10:16:52 that took me about 30 seconds on google so I expect you can find better volume pricing if you do some searching Oct 01 10:17:29 Oh Sorry, I thought, #beagle customer care. Oct 01 10:18:54 thanks scm1hewf. Oct 01 10:27:13 no worries... You might have better luck importing them from Singapore or China though Oct 01 10:27:13 Micheal: this is a community support chat, not a sales channel Oct 01 10:27:59 My Apologies zmatt Oct 01 10:28:05 no worries Oct 01 10:56:32 Hi! Does any one know now to sniff data from ser1 port on QNX 4? ser1 port is opened by some app an the boot. Oct 01 10:56:52 at* Oct 01 14:21:32 hey zmatt, with regards to that mentor graphics usb stack, do you happen to know if the usb-gadget serial and rndis make use of the built in serial and rndis functionality of the stack? Oct 01 16:16:37 In this tutorial they have an example device tree to use for the Beaglebone AI: https://www.element14.com/community/community/project14/visionthing/blog/2019/11/16/beagleboard-ai-brick-recovery-procedure#jive_content_id_PINMUXING Oct 01 16:17:26 In it, some of the pins are set to MUX_MODE15. What does this do? I believe that MUX_MODE14 is the GPIO setting. Oct 01 16:19:30 m Oct 01 16:53:15 hunter2018[m]: 15 = safe mode, i.e. no functionality Oct 01 16:53:55 Konsgnx: those were optimized dma modes iirc? Oct 01 16:54:37 Konsgnx: not sure, check the driver I guess... dma for usb is disabled on the beaglebone kernel anyway Oct 01 16:56:19 hunter2018[m]: gpio is mode 14, available for most but not all pins Oct 01 17:22:12 Thanks! Oct 01 19:31:33 Is this the correct way to toggle a GPIO on the BeagleBone AI by using the bone-pinmux-helper like this? https://pastebin.com/xmm909TQ Oct 01 19:31:58 Not sure if PIN_OUTPUT_PULLUP and PIN_OUTPUT_PULLDOWN are the same thing as writing the pin high or low. Oct 01 19:32:01 no Oct 01 19:32:21 absolutely not Oct 01 19:32:37 nor does PIN_OUTPUT configure the pin as output Oct 01 19:33:55 PIN_INPUT_* = input enabled, PIN_OUTPUT_* = input disabled. output-enable (and output value) are always controlled by the peripheral selected by the mux mode Oct 01 19:34:21 PULLUP/PULLDOWN controls a weak resistor on the pin intended to keep the pin from floating Oct 01 19:35:20 pinmux state should normally be configured once at boot Oct 01 19:38:26 bone-pinmux-helper devices are intended mostly as a way for people to configure pinmux without having to customize the device tree. since you're clearly already customizing the device tree, using bone-pinmux-helper devices is most likely nonsensical Oct 01 19:39:41 for gpio you most likely want a gpio-of-helper device. see this example for the BBB: https://github.com/mvduin/overlay-utils/blob/master/gpio-demo.dtsi Oct 01 19:40:37 when not using overlay utils the #include you want for gpio constants is and the relevant constants are GPIO_ACTIVE_HIGH and GPIO_ACTIVE_LOW (rather than just ACTIVE_HIGH/ACTIVE_LOW) Oct 01 19:41:59 to avoid writing magic constants like 0x36F0 you may want to use this #include: https://pastebin.com/vwn4m7Nf Oct 01 19:44:33 so you could write DRA7XX_CORE_IOPAD( P8_08, PIN_INPUT_PULLDOWN | MUX_MODE14 ) Oct 01 19:45:56 generally speaking I'd recommend using PIN_INPUT_* rather than PIN_OUTPUT_* since there's generally not really a downside to leaving input enabled (and sometimes it can be required in non-obvious situations), and I'd generally recommend leaving pull enabled in whatever direction is the default (which is pulldown for this pin) Oct 01 19:49:30 since u-boot still does not setup sane pin defaults hence &cape_pins_default is unfortunately still necessary, be sure to override it with sane defaults that omit _every_ _pin_ used in any other pinmux block you declare Oct 01 19:50:22 verify that everything looks okay using https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Oct 01 19:53:10 also, you labeled it as a "pru" pin... if you want to use the pin as a fast direct PRU GPIO (P8.08 is pruss1 core0 in/out 20), you should not configure to pin to gpio mode (nor use gpio-of-helper) but mode 12 (input) or mode 13 (output) Oct 01 19:54:35 with the pinmux node attached to the applicable device (&pruss1 in this case) Oct 01 19:55:07 hunter2018[m]: are you even still here? Oct 01 20:34:03 Just got back! Received an important phone call :) Let me catch up... Oct 01 20:36:21 Interesting, yeah why would you ever want to disable the input? Why in the world do they call it pin output!? Oct 01 20:36:48 yeah the naming is terrible Oct 01 20:37:22 Thanks so much! So I thought it was working because the pin was toggling, but I guess it was just the pullup/pulldown Oct 01 20:38:59 disabling input saves a tiny bit of power, and I *think* it protects the pin against extended exposure to intermediate voltages (levels which are in between logic-low and logic-high) but I wouldn't rely on that without getting confirmation from TI Oct 01 21:07:58 Hello guys. Could anyone help me with beagleboard xM ? I'm looking for a Graphic Linux. Could anyone tell me where do can i find a image ? Oct 01 21:09:15 uhh I'm pretty sure the recommended beagleboard.org images for the xM all include a GUI Oct 01 21:10:46 "OMAP3/DM3730 Debian 9.5 2018-10-07 4GB SD LXQT image for BeagleBoard, BeagleBoard-xM" under "Recommended Debian Images" at https://beagleboard.org/latest-images Oct 01 21:11:49 Thank you Oct 01 22:48:54 hunter2018[m]: oh and if you want to use pru direct outputs (via r30), beware that r30 is not zero-initialized after reset but contains random values, so that's a rare case where it may be advisable to use a 2-state bone-pinmux-helper to keep the pins in safe mode until you've had a chance to initialize r30 and only then switch the pins to pru output mode Oct 01 23:01:37 Yeah, I might need to do that anyway because I have a chip that needs the SPI clock signal high (or low, I can't remember) during startup. Anyway, the default SPI behavior causes problems. Oct 01 23:02:33 if you need a pin to have a particular level immediately after power-up, either use a pin whose default internal pull has the correct direction, or override that default internal pull with a strong external pull resistor Oct 01 23:03:24 though an spi slave device is not supposed to care about the state of the clock line (nor mosi line) unless its chip select is asserted Oct 01 23:03:48 since with chip select deasserted, the bus may be in use for other spi slaves Oct 01 23:33:43 do you guys know of an armhf platform with more than 5 bytes of RAM? Oct 01 23:34:03 or .. maybe is there a way to virtualize in such a way that linux could be booted Oct 01 23:34:15 for purposes of toolchain and building Oct 01 23:43:30 there are pretty big armhf systems as well as arm64 systems that can run armhf VMs. on the other hand it's often also possible to cross-compile stuff from a beefy x86 system Oct 01 23:45:38 so maybe on a a1.xlarge ? Oct 01 23:46:54 A1 instances are the first EC2 instances powered by AWS Graviton Processors that feature 64-bit Arm Neoverse cores and custom silicon designed by AWS. Oct 01 23:47:01 your question is really broad and vague so it'll be difficult for anyone to give useful feedback Oct 01 23:48:19 Well, I'd be interested in any reasonable possibility... if "large" is expensive, maybe cloud and virtualization would be a way to go Oct 01 23:49:25 I think cross-compiling probably won't work Oct 01 23:50:00 is this still about this python lib? Oct 01 23:50:05 yep Oct 01 23:51:28 ooh. found qemu-system-arm Oct 01 23:51:50 you can expect that to be hideously slow Oct 01 23:52:25 like factor of 2 or factor of 10 slow Oct 01 23:52:39 that sounds optimistic to me Oct 01 23:53:00 but maybe I'm wrong] Oct 01 23:57:02 slower than swapping a ton to an SSD Oct 01 23:57:04 ? Oct 01 23:57:25 my other possible experiment is to set up a large SSD swap partition from USB drive Oct 01 23:57:43 i think gcc is running out of memory Oct 02 00:08:34 new blue arrived today Oct 02 00:08:34 okay qemu-arm doesn't seem *that* bad... using sha256sum as a simple cpu benchmark, I got: bbb 28MB/s, bbx15 57 MB/s, my laptop (qemu-arm) 100 MB/s, my laptop (native) 200 MB/s Oct 02 00:09:01 that's better than I expected Oct 02 00:16:08 Nice! Oct 02 00:38:27 had some interesting stuffs on it Oct 02 00:41:07 What do you mean? Oct 02 00:41:18 Like, a helicopter? Oct 02 00:41:20 Ha. Oct 02 00:41:39 it was used Oct 02 00:41:43 from ebay Oct 02 00:41:49 Oh. Oct 02 00:41:51 Okay. Oct 02 00:41:53 so they stuff they did was on there Oct 02 00:42:27 I am trying to learn how to use this metal bender and the instructions are broken English. Oct 02 00:42:38 So, there is not a way to figure out exactly what they mean. Oct 02 00:42:43 pic Oct 02 00:42:49 Of the instructions? Oct 02 00:42:54 the bender Oct 02 00:43:02 Oh. Okay. Please hold. Oct 02 00:46:45 https://i.imgur.com/xJYDyw9.jpg is the thing in its resepctive case. Oct 02 00:47:09 I literally almost jabbed my lilly, white skin. Oct 02 00:47:18 close call. Ha. Oct 02 00:48:10 brb Oct 02 00:48:19 ic Oct 02 00:48:26 not seen one like that before Oct 02 00:52:55 It is for tiny, modeling. Oct 02 00:53:16 I plan on putting a tiny model together for my bot-BBB efforts. Oct 02 00:54:14 I got some 5/32" music wire and rods. So, those rods are supposed to be able to be cut and bent for the bot and my BBB brain. Oct 02 00:54:59 if you show it out of the case could probably tell you what to do Oct 02 00:55:13 Plus, when Maker Faire rolls around in 2021, I need to have something ready. Hmm. Really? Oct 02 00:55:53 Okay. Let me show you the info. of the instructions (all pages). I will be a bit of time but I can get it fixed up nicely. Oct 02 00:55:58 Is that okay? Oct 02 00:56:08 om guessing opposite the big wheel it is keyed to put that handle Oct 02 00:56:17 No. Oct 02 00:56:30 well lets see Oct 02 00:56:39 There are blocks that are...okay. Please hold. Oct 02 00:56:51 can you just show a pic of it out of the box Oct 02 00:57:17 Sure. Oct 02 00:57:34 I will get some cardboard to put it on so it does not get the ground greasey! Oct 02 00:58:42 for some reson i have in my head its a roller bender but i think its not Oct 02 01:01:30 zmatt: howd you do that? Oct 02 01:02:04 was it armhf? Oct 02 01:02:21 ?? Oct 02 01:02:24 do what? Oct 02 01:02:25 i could only find some cell phone CPUs that looked similar Oct 02 01:02:37 run an armhf benchmark in qemu Oct 02 01:04:01 I used qemu-user-static with systemd-nspawn on a mounted beagelebone image Oct 02 01:04:10 time dd if=/dev/zero bs=4M count=100 status=none | systemd-nspawn --directory=/mnt/tmp --bind-ro=/usr/bin/qemu-arm-static --link-journal=no --quiet --as-pid2 --pipe /usr/bin/sha256sum Oct 02 01:04:29 renrelkha: Let me bring up the info. on a page online so we can make ideas available instead of taking up space for a bender in here. Oct 02 01:05:30 s_: nothing you described suggests any need/utility to do full system emulation let alone emulate something resembling a bbb Oct 02 01:06:47 shouldn't it be armhf? Oct 02 01:06:58 this is armhf Oct 02 01:08:04 this what? Oct 02 01:09:11 I don't understand your question.. shouldn't what be armhf? "armhf" refers to arm eabi with hard fpu abi, it specifies how your userspace stuff is compiled Oct 02 01:09:36 the image I had mounted at /mnt/tmp was a beaglebone image, which is an armhf image Oct 02 01:12:25 and qemu-arm by default emulates a generic armv7-a processor, though you can tweak that through environment variables if desired Oct 02 01:12:32 https://app.conceptboard.com/board/8ady-kk34-5h7d-g95t-hdf6 Oct 02 01:12:36 zmatt: ill need to read more about that command to understand it fully, i believe, but i think i can see what you did for the benchmark Oct 02 01:12:50 That is the photo of the parts I used. Oct 02 01:14:41 s_: I spawned a container on a mounted beaglebone image and ran the sha256sum utility inside it. thanks to binfmt_misc my kernel recognizes arm executables and automatically uses qemu-arm-static to run these, which it could since I made sure to bind-mount it into the container Oct 02 01:19:13 e.g. to just spawn a root shell inside the container you can use: systemd-nspawn --directory=/mnt/tmp --tmpfs=/tmp --bind-ro=/usr/bin/qemu-arm-static --link-journal=no --hostname=beaglebone Oct 02 01:19:39 this can be pretty useful for working on filesystem images Oct 02 01:26:24 let me try this approach Oct 02 01:59:28 magic. wow. Oct 02 01:59:47 that is pretty cool. Oct 02 02:02:10 hmm... TMPDIR=/tmp is set to a non-accessible location Oct 02 02:03:40 interesting... tmp was not 777 Oct 02 02:12:22 i mean emulating arm within an ubuntu vm.. maybe a little ugly Oct 02 02:15:31 zmatt: any suggestions how one might pass -smp 4 to that qemu command? Oct 02 02:28:38 qemu: unknown option 'smp' Oct 02 02:29:15 hmm. I must have that option wrong Oct 02 02:29:30 pretty sure qemu-user does not affect processes or scheduling, so the option makes no sense Oct 02 02:34:13 yes, I think you're right Oct 02 02:36:25 Is beagle bone black running mainline kernel? Oct 02 02:39:45 you asked that question before and got an answer already Oct 02 02:40:44 fling: https://pastebin.com/Uux2zXLa Oct 02 02:41:42 thanks Oct 02 02:44:21 zmatt: what is the repo for this ti kernel? Oct 02 02:46:03 https://github.com/RobertCNelson/ti-linux-kernel-dev is the repo containing the patches, kernel config, and build scripts (that will fetch TI's kernel tree via git, apply patches, apply config, give you opportunity to customize the config, compiles the kernel, and builds a .deb package from it) Oct 02 02:46:58 select branch for the kernel version desired Oct 02 02:47:19 (ti-linux-4.19.y is the default kernel series currently) Oct 02 02:47:50 https://github.com/RobertCNelson/bb-kernel is the same for the -bone kernel series which are very close to mainline Oct 02 02:48:25 >> repo containing the patches Oct 02 02:48:29 are the patches separated? Oct 02 02:48:38 oh wait it does not have the tree Oct 02 02:49:02 * fling checking Oct 02 02:51:54 yeah the patches are maintained as patches that the build scripts apply to the upstream source tree Oct 02 02:52:47 which for -bone kernels is mainline, and for -ti kernels is git.ti.com/ti-linux-kernel/ti-linux-kernel.git Oct 02 02:59:36 are you saying ti patches are applied to a custom repo and not mainline? Oct 02 02:59:40 what is this repo doing? **** ENDING LOGGING AT Fri Oct 02 02:59:57 2020