**** BEGIN LOGGING AT Wed Oct 23 02:59:58 2019 Oct 23 09:31:46 PeterL Oct 23 09:32:45 Hi zmatt: u kiu kndly offered to help with my bbb no pru situation Oct 23 09:33:38 Ive got the .dts files and uEnv.txt in pl.zip I could put on pastebin Oct 23 10:26:29 PeterL Oct 23 10:28:09 zmatt - I'm having BBB trouble with PRUs. You offered to look at the .dts file and uEnv.txt. I can post a .zip file on pastebin **** BEGIN LOGGING AT Wed Oct 23 12:05:11 2019 Oct 23 12:58:32 Guest29999: Can you post your uEnv.txt on pastebin? Guest29999 Oct 23 13:10:46 Guest29999: you can't put zip files on pastebin, create separate pastes with the contents of /boot/uEnv.txt and your dts file. also, if you want help with something, always provide enough information so someone who glances at chat could actually help you. right now I'm here and could have looked at your .dts *if you had shared it*. perhaps later you will share it, but I probably won't be here. ... Oct 23 13:10:52 ...you're not making efficient use of a help resource this way Oct 23 13:13:06 also by addressing me directly you're limiting your audience. just state your problem / ask your question in a self-contained way so anyone can (try to) help you. also don't assume I remember what you said days ago (I happen to in this case, but it's a bad assumption in general) Oct 23 13:13:31 anyway, afk again Oct 23 13:26:55 How can you check pinmux to see if pins are setup the way you think they are on the Beaglebone AI? Oct 23 13:28:37 hunter2018[m]: I have a version of show-pins for the bbx15 but its pin labels would need to be updated for the bbai, jkridner also made a modified version of an ancient version of my show-pins script for the bbai but I don't remember where in /opt it's installed Oct 23 13:29:29 maybe check with ls /opt/**/show-pins (make sure the use of ** is enabled in bash with shopt -s globstar ) Oct 23 13:29:41 or maybe it's show-pins.pl Oct 23 13:31:02 : /opt/scripts/device/bone/show-pins.pl Oct 23 13:34:30 Got it, but I've never used perl and I am getting the following error https://pastebin.com/raw/Kh5tLKxJ :( Oct 23 13:34:41 I guess I just need to install the Inline::Files module Oct 23 13:35:18 missing package in the factory default.. .give me sec.. Oct 23 13:36:07 hunter2018[m]: libinline-files-perl or something like that is the package name for apt Oct 23 13:36:44 sudo apt install libinline-files-perl Oct 23 13:37:24 Got it, I just tried something I found on google to use the cpan shell to install the Inline:Files module but that failed, let me try the apt install Oct 23 13:38:56 Sweet! It worked! Oct 23 13:39:15 https://pastebin.com/raw/CXZri7AG Oct 23 13:40:35 strange that it's not showing the device and pinmux node for most pins Oct 23 13:40:53 unless you disabled the cape_default_pins thing and these are actually the u-boot defaults Oct 23 13:41:31 I'm reading the script to figure out what the columns represent now... Oct 23 13:41:37 that pr1_uart0_rts_n on P8.34b seems pretty random Oct 23 13:41:46 might want to pipe the output through sort btw Oct 23 13:41:48 $label, $pin, $abc_ball, $mux-3, $function; Oct 23 13:42:25 it probably mostly matches the current documentation for show-pins: https://github.com/mvduin/bbb-pin-utils/blob/master/README.md Oct 23 13:42:47 except he added a column for the ball Oct 23 13:42:56 and gpios don't show the gpio state Oct 23 13:43:46 and his mux column is in hex rather than decimal Oct 23 13:51:33 Here is my sorted show-pins output: https://pastebin.com/raw/n4TiLtD7 Oct 23 13:56:52 Looks like the pins are setup correctly. BTW related question, I noticed some pins on the BBAI (P8.23 and P8.34a) both have pinmode 12 map to "pr 1 pru 0 gpi11[i]" Does this mean it would be ok to use either of these? Oct 23 13:57:28 I didn't realize that you would ever have a pru output/input register bit map to two different pins. Oct 23 13:58:26 yes, lots of signals have more than one pin you can map it to Oct 23 13:59:00 if there are timing constraints between related pins you may need to adhere to an "io set" though Oct 23 13:59:08 If both of these pins were put in mode 12 then they would just mirror each other all the time? Oct 23 13:59:31 for inputs it would result in undefined behaviour Oct 23 14:00:02 for output I'm not sure if muxing to two pins is officially permitted but I'd expect it to simply mirror the signal on both pins Oct 23 14:00:38 you can find iosets in the IOSets tab of the pins spreadsheet I linked previously Oct 23 14:00:45 brb Oct 23 14:07:30 What does an io set mean? I see that gpi8 of pruss1 pru has pin 130 (P8.34a) in the left column and pin 229 (P8.23) in the right. So it is better to pick either the left column or right column and stick with it for all pins? Oct 23 14:10:46 that's what an ioset means yes, but whether it genuinely matters or not depends on whether you have tight timing constraints between the pins (for which correct iodelay configuration may also be required) Oct 23 14:15:33 Hello beagle Oct 23 14:15:51 Is there anyone to support tech details Oct 23 14:16:05 jkridner[m]: the schematic is showing P9.13 only connected to one processor ball, but your version of show-pins shows it connected to two processor balls... which is true? Oct 23 14:16:44 Karthy: don't ask to ask, just ask your question and have patience. plenty of knowledgeable people here at all times, but most only glance at chat occasionally Oct 23 14:21:37 hunter2018[m]: I've made a quick bbai version of my latest show-pins script in case it's of any use => https://github.com/mvduin/bbb-pin-utils/tree/bbai-experimental#show-pins Oct 23 14:22:36 note that it uses 0-based indexing for everything, matching my spreadsheet (as well as the kernel numbering of some devices such as i2c devices and uarts) Oct 23 14:23:51 hunter2018[m]: btw I see pru gpi pins with no pull-up/down enabled in your paste... that's not good Oct 23 14:30:51 Thanks! I tried your script , but it says it died at line 103 https://pastebin.com/raw/vp2j5iXD Oct 23 14:31:06 hmm what now Oct 23 14:31:44 oh right, that issue Oct 23 14:31:53 change the 'or die' on that line to 'or last' Oct 23 14:31:59 I'll need to fix that at some point Oct 23 14:32:13 but breaking out of the loop is an adequate workaround Oct 23 14:33:10 committed and pushed the workaround Oct 23 14:33:49 github doesn't serve last-modified headers? that's fucking annoying Oct 23 14:37:37 Thanks! So I downloaded the script again and no error, but I don't see any output either... https://pastebin.com/raw/H2sZV38t Oct 23 14:37:52 ehhhhh Oct 23 14:38:16 ohh duh.. I'm guessing output does show up with -v ? Oct 23 14:38:29 filtering is probably wrong because the expansion header names are different, one sec Oct 23 14:38:44 yep, that works! Oct 23 14:38:56 yeah bingo, found it Oct 23 14:40:42 comitted and pushed Oct 23 14:42:04 Thanks, so today as I've been ssh's into my BBAI the connection keeps stopping for 5 seconds or so and then working for like 20 seconds, then stopping again. Not sure if it is the BBAI or the network. I'm going to reboot everything. It's making it almost impossible to do anything over ssh. Oct 23 14:42:36 *ssh'ed Oct 23 14:42:40 that sounds obnoxious Oct 23 14:44:04 I don't guess it could have happened after I modified my device tree, or if it could be caused by that bus error you saw in the kernel log. Oct 23 14:44:16 neither sounds particularly likely Oct 23 14:44:48 Good to know, Oct 23 14:45:11 what does sudo show-pins | sort look like now btw? Oct 23 14:51:16 here is the output of show-pins now: https://pastebin.com/raw/fJbYxv2r Oct 23 14:54:26 so did you disable cape_default_pins entirely? since those pruss 0 gpi pins should definitely be fixed Oct 23 14:57:04 hello. Oct 23 14:57:48 my BBB has too much boot time. I need to find what's teh cause: Oct 23 14:58:28 from dmesg i see a jump of 20 seconds between two events. Oct 23 14:59:16 the line before this 20 seconds interval says: Oct 23 14:59:17 IPv6: ADDRCONF(NETDEV_UP): usb1: link is not ready Oct 23 14:59:56 is this the cause of that 20 seconds "waiting"? Oct 23 14:59:59 no Oct 23 15:00:17 it can be hard to tell what is waiting for something from just a kernel log Oct 23 15:00:32 are you running a recent image? Oct 23 15:00:48 in /boot/uEnv.txt make sure the cmdline variable includes "rng_core.default_quality=100" Oct 23 15:01:00 from may 2019 Oct 23 15:01:11 also make sure your bb-customizations package is uptodate Oct 23 15:01:28 that's an unusual date... I don't think there was an official image release with that date, just testing images Oct 23 15:01:37 what's that? Oct 23 15:01:47 what's what? Oct 23 15:01:47 wait, i'll copy the version Oct 23 15:02:02 you can find the image date in /etc/dogtag Oct 23 15:02:42 debian@beaglebone:~$ cat /proc/version Oct 23 15:03:04 don't try to paste multi-line output into chat Oct 23 15:03:28 use a paste service like pastebin.com (or in this case just paste the single line of output from that command) Oct 23 15:03:41 dogtag: BeagleBoard.org Debian Image 2019-05-27 Oct 23 15:04:12 okay, so a testing image Oct 23 15:04:33 probably doesn't matter Oct 23 15:04:46 anyway, check the two things I mentioned Oct 23 15:05:01 what's the customization package? Oct 23 15:05:33 a package with scripts and config files specific to beaglebones Oct 23 15:06:58 no rng_core lines in my uEnv.txt Oct 23 15:07:05 should i add that line? Oct 23 15:07:32 add it at the end of the existing cmdline= definition (separated by a space) Oct 23 15:08:14 cmdline=coherent_pool=1M net.ifnames=0 quiet cape_universal=enable rng_core.default_quality=100 Oct 23 15:08:20 like this? Oct 23 15:08:38 cape_universal=enable does nothing on current systems Oct 23 15:09:04 so you can remove that bit Oct 23 15:09:09 other than that yes Oct 23 15:10:13 ok. about that package... where can i get it? Oct 23 15:11:00 for the bb-customizations package... if your bbb has internet access, you can update it by first updating the package lists with "sudo apt update" and then you can update the package specifically with "sudo apt install bb-customizations" (you can also update all packages with "sudo apt upgrade") Oct 23 15:12:38 if it indeed installs a new package (i.e. your current version wasn't uptodate) then after it has installed it you should also update your initramfs to get all performance benefits (iirc "sudo update-initramfs -u") Oct 23 15:13:08 ok thanks .... Oct 23 15:13:11 i've just flashed 8 BBB with my current image :( Oct 23 15:13:17 or better yet, remove initramfs entirely since the bbb doesn't need one and it boots faster without it Oct 23 15:13:24 uhh, why did you flash it with an old image? Oct 23 15:13:31 may isn't the latest one Oct 23 15:13:32 zmatt: here is my device tree https://pastebin.com/raw/1qN0Gwfp Oct 23 15:14:19 i've got bad experiences with updated images and my own software, so i stay where i'm sure it works Oct 23 15:14:27 Parduz: okay that's fine Oct 23 15:14:37 zmatt: and here is bbai-spi-test.dtsi https://pastebin.com/raw/grCki8Cq Oct 23 15:14:51 but then it would have been a good idea to test one image thoroughly (and fix issues like these) *before* flashing it to 8 others :) Oct 23 15:15:19 agreed. I'm not my boss ;) Oct 23 15:15:57 so, there's one image i should pick, or just the most updated/not-testing one? Oct 23 15:16:14 Parduz: so, if you're trying to optimize boot time, just to make you jealous, this is quite possible => https://liktaanjeneus.nl/boot.svg Oct 23 15:16:39 uh! Oct 23 15:16:46 zmatt: If I did what I think I did, then I didn't disable cape_default_pins entirely, just commented out the pins I'm using. Oct 23 15:16:50 with LXQT or without a desktop? Oct 23 15:17:40 that's a very minimal system... I wouldn't want to run lxqt on a beaglebone anyway... but I don't think a gui would add many seconds to it Oct 23 15:17:44 *should add Oct 23 15:18:45 We use BBB with our own LCD cape and wxWidgets "kiosk" app, so i need it Oct 23 15:18:52 LXQT (lightdm) waits for urandom, so it's even slower before rng_core.default_quality=100, grab the iot or console for speed Oct 23 15:19:29 it's actually faster to grab an iot image, add openbox and have your 'kiosk' load: Oct 23 15:19:34 Parduz: we use beaglebones in GUI applications, but just using qt5 directly on the framebuffer (you can use either linuxfb or eglfs) Oct 23 15:19:43 no x11 Oct 23 15:19:51 it used that here: https://www.digikey.com/eewiki/display/linuxonarm/FLIR+Lepton+on+BeagleBone+Black+and+Green Oct 23 15:21:12 ok. i'll take a look at that. Oct 23 15:21:39 as long as wxWidgets works on that Oct 23 15:22:25 Parduz: disabling initramfs removes another 5 seconds from boot time, so that may be worthwhile... for testing that you can delete or rename your /boot/initrd* file. for a more permanent solution get rid of the initramfs-tools package. unfortunately the kernel package has an inappropriate dependency on the initramfs-tools package, but a workaround is replacing it by a dummy package I made: ... Oct 23 15:22:31 ...https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb Oct 23 15:23:13 this causes problems with very old kernels (before 4.9 iirc) but that shouldn't matter Oct 23 15:23:22 there is a qt5 wxwidgets port, so you might be able to use zmatt's boot right into qt5 Oct 23 15:23:45 getting qt5 on the framebuffer as a startup service can be a bit fiddly iirc Oct 23 15:23:58 moreso with the eglfs backend than the linuxfb one Oct 23 15:25:49 hunter2018[m]: since cape_pins_default depends on all pinmux setup in your entire .dts, it should probably go to your .dts and not any .dtsi Oct 23 15:26:14 hunter2018[m]: ohh... the PIN_INPUT (without pull) are like that in the original cape_default_pins ? yikes Oct 23 15:26:55 rcn-ee[m]: current cape_pins_default seems to set up some pins as input with no internal or external pull-up/down Oct 23 15:27:12 rcn-ee[m]: that's a really bad idea and may damage the I/O cells in the long term Oct 23 15:29:49 hunter2018[m]: btw you're using P8.34a, not P8.34b, you commented out the wrong one Oct 23 15:30:33 zmatt: Why should cape_pins_default go in .dts and not .dtsi? Isn't it fine as long as my modifications come after the cape_default_pins node is created? Oct 23 15:31:11 hunter2018[m]: the problem is that you need to comment out every line in cape_pins_default that's used by pinmux setup in any part of your .dts (including any .dtsi files you include) Oct 23 15:31:38 there's no way for a .dtsi file to just remove the pins it uses from cape_pins_default Oct 23 15:31:45 which is why cape_pins_default just needs to die Oct 23 15:32:22 it is incompatible with any sort of DT modularity Oct 23 15:34:25 hunter2018[m]: what happens if you just disable it entirely with https://pastebin.com/ZyMeL5mT (in your .dts) ? what does the pinmux look like then? Oct 23 15:34:47 zmatt: why can't it just be removed in any overlay? what could be done that would be modular? cc rcn-ee[m] Oct 23 15:35:07 jkridner: why does it exist in the first place? just setup default pinmux in u-boot Oct 23 15:35:38 sorry, the router crashed :( Oct 23 15:35:45 zmatt: hmmm. true. Oct 23 15:35:48 jkridner: do we wish to support multple overlays. ;) i don't.. Oct 23 15:36:13 jkridner: also, it muxes some pins to an invalid mode (gpio mode on pins with no gpio functionality) and it muxes some pins to input with no pull-up/down (i.e. floating), which is potentially bad for the hardware Oct 23 15:36:46 rcn-ee[m]: multiple overlays are often quite handy Oct 23 15:37:01 zmatt: the pins that float should all be tied to pins that aren't floating. if not, that is an oversight. Oct 23 15:37:14 why the talk of multiple overlays? Oct 23 15:37:36 because cape_default_pins makes the use of multiple overlays impossible Oct 23 15:37:46 (and same for any sort of modularity in the main .dts) Oct 23 15:38:22 btw, I have some more distractions today, but am still going to be back to work on https://github.com/jadonk/u-boot/tree/upstream-add-ai-20191015 within the next day or two. Oct 23 15:38:34 I *really* need to get this submission done. Oct 23 15:39:19 since all you can do in an overlay is replace the cape-pins-default list by one that omits the pins used by the overlay... but then only the last overlay will work since it won't know about the previous ones Oct 23 15:39:55 but like I said, I don't understand why it exists at all... if you want different defaults than the hardware defaults, then configure those in u-boot Oct 23 15:40:04 and the floating pins are not tied to non-floating ones Oct 23 15:40:20 not all anyway Oct 23 15:41:01 k. let's get those all correct in the u-boot submission. I'll review here and on the list. Oct 23 15:41:14 jkridner: there's also a pin myseriously muxed to a pruss uart rts signal Oct 23 15:41:36 that is odd. Oct 23 15:41:57 oh yeah that's not in your version Oct 23 15:41:59 I haven't reviewed it in some time as I'm more worried about just getting the eMMC working in u-boot for now. Oct 23 15:42:31 ? how are people booting if eMMC isn't working in u-boot? Oct 23 15:42:32 I'll use show-pins to review the pin states once I've got the boot. Oct 23 15:43:05 ideally, I'd want to also comprehend moving the signature into u-boot environment variables or some other less obtrusive mechanism. Oct 23 15:43:25 the signature? Oct 23 15:43:29 oh, just my version of u-boot that accesses eMMC extra early for the serial number read junk. Oct 23 15:43:37 signature, serial number, whatever. Oct 23 15:43:40 boardid. Oct 23 15:43:42 ah Oct 23 15:44:34 oh yeah, that's a big problem... it isn't actually safe to try to access eMMC in a multi-board u-boot since some boards might use those pins for a different purpose Oct 23 15:44:57 at least you'd need to try eeprom identification first (since that's standardized by TI iirc) and fall back to eMMC Oct 23 15:45:01 I test to see if the boot mode is 2, matching BeagleBone AI. Oct 23 15:45:13 and, I did leave the EEPROM detection in the loop first. Oct 23 15:45:17 good! Oct 23 15:45:23 yeah those sound like good solutions Oct 23 15:45:35 * jkridner breathes a deep sigh. Oct 23 15:45:57 I mean, as far as ugly workarounds to an absent identification eeprom go Oct 23 15:45:58 ;) Oct 23 15:46:08 :-D Oct 23 15:46:28 all I can expect. I mean, the EEPROM *really was* in the spec. Oct 23 15:47:24 got to the point that nothing would move forward unless I said there were no more hardware changes. :-( Oct 23 15:47:31 so, I said we could live with this. Oct 23 15:47:52 hunter2018[m]: also beware of pull-pull conflicts: when configuring one member of a pair of pins tied together, make sure you don't configure it with a pull that opposes the other member. preferably always configure both pins in the same pinmux block so they stay together (with the unused one muxed to safe mode) Oct 23 15:47:59 A2 layout got done, but still isn't complete of all the changes we should have. Oct 23 15:48:32 jkridner: btw when I pointed out some pins were muxed to gpio mode even though they don't have a gpio mux mode rcn-ee[m] said there was a reason to not mux them to safe mode... what is that reason? Oct 23 15:48:43 we are considering having the default pinmuxes match the robotics cape to give a number of useful pin modes by default.... Oct 23 15:48:56 my biggest concern there is having any pin configured as an output by default. Oct 23 15:49:06 yeah sounds like a bad idea Oct 23 15:49:45 zmatt: the reason I put some in GPIO mode instead of OFF was that OFF seems to try to enable a pull-up or pull-down and those sometimes conflicted with shorted pins. Oct 23 15:50:00 it isn't that we shouldn't use OFF mode for the pins. Oct 23 15:50:34 I'm told now there is a way to keep them in OFF mode, but still disable the pull-up/down in the case that another pull-up/down is already enabled on a shorted line. Oct 23 15:50:40 that would be the preferred approach. Oct 23 15:50:52 off mode affects pull-up/down? Oct 23 15:51:02 that sounds really bizarre... is that documented behaviour? Oct 23 15:51:46 haven't looked. just observed with pins shorted on I2C. Oct 23 15:52:40 I noticed that configuring pins shorted to I2C pins to OFF mode caused the I2C to fail. Oct 23 15:52:49 and I should really try to dig into u-boot to see if I can get my idea to work, to allow u-boot to reconfigure pinmux/iodelay safely (glitch-free) based on DT once it has been loaded from disk (and overlays have been applied) Oct 23 15:52:57 I observed that if I turned off the pull-up/down and put the pins in GPIO mode, I2C worked. Oct 23 15:53:13 zmatt: that'd be amazing. Oct 23 15:53:21 in theory it shouldn't be that hard... Oct 23 15:54:58 hmm Oct 23 15:55:46 still, it doesn't seem like a good idea to mux pins to gpio if they don't have a gpio mode in the first place (which currently happens on 6 balls by default) Oct 23 15:57:15 is it a hassle to request a pull-request fix? Oct 23 15:57:47 and if off-mode messes with configured pull-up/down or presents a lower impedance than gpio mode then if confirmed that sounds like it should be an official erratum Oct 23 15:57:58 on which repository? Oct 23 16:02:03 btw for making a device that just sets up pinmux (and nothing else) I think it would be better to use gpio-of-helper rather than gpio-leds ... I noticed the pins don't seem to remain claimed by any driver so I suspect probe fails, while I'm pretty sure gpio-of-helper doesn't care Oct 23 16:02:57 gpio-of-helper was originall written for 3.8.x so it's doesn't care about alot of things. ;) Oct 23 16:03:26 it's still working fine today and I consider it an absolutely essential driver Oct 23 16:03:39 it probably could use a bit of cleanup Oct 23 16:04:05 but on mainline. ;) Oct 23 16:04:14 but there's no good alternative for setting up gpios in DT for use by userspace Oct 23 16:04:15 * but not mainline. ;) Oct 23 16:04:28 on/not... Oct 23 16:04:42 it belongs on mainline in my opinion, but mainline seems to have the mistaken idea that the new gpio chardev is a usable replacement for the sysfs interface Oct 23 16:04:57 yeah there all terible.. Oct 23 16:06:59 gpio-of-helper allows me to name and configure individual gpios for use by userspace (including initial pin direction, whether or not the pin is bidirectional, the default output level for outputs) which (thanks to an udev rule) userspace can access via /dev/gpio/$NAME without having to know or care about which pin or which gpio controller was used (which tends to vary between board revisions) Oct 23 16:07:26 it also allows for per-gpio access control granularity Oct 23 16:07:58 see, it's too useful for mainline. ;) Oct 23 16:09:37 I've considered posting my gpio sysfs improvement patches (perhaps along with the gpio-of-helper after cleanup and review) to the appropriate mailing list with a rebuttal rant prepared for the inevitable person saying the chardev should be used, but I don't know if I have the energy Oct 23 16:10:57 jkridner: I'd be happy to do a pull request for the default pins in dts and/or u-boot, just let me know which github repositories those should go to Oct 23 16:19:14 jason's wip u-boot tree for mainline is here: https://github.com/jadonk/u-boot/tree/upstream-add-ai-20191015 Oct 23 17:18:27 Hello. Does anyone know why the Beagleboard x15 isn't available anywhere? Oct 23 17:22:20 mouser says they have 491 units on order, expected in less than a month Oct 23 17:22:25 https://www2.mouser.com/ProductDetail/?qs=mAH9sUMRCtul7OWq6qLH4g%3D%3D Oct 23 17:26:01 Ok, thank you. Oct 23 18:14:03 Turns out my slow ssh was just my network. I connected to the wireless AP the BBAI makes and now it is fast again. Oct 23 18:15:24 I wouldn't be surprised if its wifi reception is less-than-superb Oct 23 18:32:09 zmatt: I'm going to try deleting the cape-pins node now. Did you mean delete cape-pins or cape_default_pins? Oct 23 18:32:45 cape-pins is a node that exists solely to activate the &cape_pins_default pinmux node Oct 23 18:32:49 Here Oct 23 18:33:09 deleting the node like I showed in my snippet is the best solution Oct 23 18:33:26 another option would be to set its pinctrl-0 node to <> Oct 23 18:34:32 I'm pretty sure that setting the pinctrl-single,pins property of &cape_pins_default to <> is invalid and will cause the kernel to complain Oct 23 18:43:50 Ok, cool. Here is my show-pins before deleting the node (and after fixing my P8.34a/b mistake): https://pastebin.com/raw/05DqirFH and here it is after deleting the node: https://pastebin.com/raw/QsPjC0jb Oct 23 18:44:43 i.e. no effect at all? Oct 23 18:45:00 Yeah, they look identical... Oct 23 18:46:02 Here is my .dts file, https://pastebin.com/raw/rfnwas7f Oct 23 18:46:53 and the bbai-spi-test.dtsi no longer contains a cape_pins_default block? Oct 23 18:47:09 (it shouldn't have any effect anymore even if it does, but just in case) Oct 23 18:47:55 Actually it does, I didn't change it. I can go back and remove that now... Oct 23 18:49:43 btw please fix the pull-up/down conflict on P8.31 Oct 23 18:52:19 Ok, here is my bbai-spi-test.dtsi now: https://pastebin.com/raw/fzGH11j7 Oct 23 18:52:55 it is not harmful to include dra7-uio-pruss.dtsi twice btw... ideally I'd want to use #pragma once but doing so doesn't make much sense unless all the dtsi files use it... then each one could also just #include their dependencies instead of having to use a comment "// please include this after yada yada..." Oct 23 18:53:02 I changed DRA7XX_CORE_IOPAD( 0x3400 + 4 * 133, PIN_INPUT_PULLUP | MUX_MODE12 | MODE_SELECT ) // P8.31 in 11 (mosi) to DRA7XX_CORE_IOPAD( 0x3400 + 4 * 133, PIN_INPUT_PULLDOWN | MUX_MODE12 | MODE_SELECT ) // P8.31 in 11 (mosi) Oct 23 18:53:28 that should fix it yes Oct 23 18:53:33 So now P8.31 should only have pulldowns Oct 23 18:55:04 and like I said, I recommend always putting both pins of a tied-together pair in your pinmux blocks, with the unused one set to mode 14 (gpio) or 15 (safe) with pull up or down as appropriate... that also ensures the pin is considered "occupied" by the kernel and no other driver can allocate it (which would be a conflict) Oct 23 18:57:30 not a hard requirement, just a style recommendation :) Oct 23 19:00:03 Good idea, I rebooted and now things have changed causing some pin pair pulldown/up conflicts again: https://pastebin.com/raw/MV1Bm6XG Oct 23 19:00:19 ok so *this* is u-boot's default config Oct 23 19:00:44 jesus christ what is this awful mess Oct 23 19:00:58 this looks like it's not remotely intended for the bbai Oct 23 19:01:33 you must have made a mistake earlier when you saw no difference Oct 23 19:02:04 this is pretty bad, it even looks like some pins are configured as output by default Oct 23 19:02:26 Well, I still had cape_pins_default block, I think it changed after I removed that. Oct 23 19:02:29 anyway, based on this you'll definitely need cape_pins_default until u-boot is fixed Oct 23 19:02:35 that's really weird since it shouldn't be referenced Oct 23 19:03:19 I'm not ruling out that I did something dumb though... Oct 23 19:03:24 besides, removing your override of the block should only cause it to revert to the default defined in am5729-beagleboneai.dts Oct 23 19:04:15 anyway, this is really not okay, not even transiently between start of u-boot and when the kernel gets around to configuring pins according to DT Oct 23 19:04:19 so this really needs to be fixed in u-boot Oct 23 19:04:49 but until it is you'll need cape-pins Oct 23 19:06:09 I'm assuming fixing the u-boot default config isn't as easy as it is to make a device tree right? Oct 23 19:06:54 it's just a big array somewhere in u-boot.. Oct 23 19:07:42 I suspect it's currently using the am572x-evm pinmux Oct 23 19:24:40 does this look ok for moving cape_pins_defalut from my .dtsi and into my .dts file? https://pastebin.com/raw/8FUJGqiX Oct 23 19:25:08 &cape_pins_default { Oct 23 19:25:44 you are modifying the contents of an existing node, not creating a new node Oct 23 19:26:05 ahhh, I keep doing that. Thanks! But it is ok to go in the bottom like that? Oct 23 19:26:21 sure why not Oct 23 19:26:46 that's exactly where you had it in bbai-spi-test.dtsi .. which was directly #included into your dts, so that was equivalent to having it at the bottom of your .dts Oct 23 19:28:20 Ok, makes sense Oct 23 19:30:13 order of fragments (top-level blocks) matters only when they're overriding each other, but fragments that affect different parts of the DT can be in whatever order you like Oct 23 19:31:29 oh and I think &label references must come after the labeled node except when the &label is inside <> in a property value (for which dtc can resolve forward references) Oct 23 19:35:15 https://pastebin.com/raw/XFCG2yBF the three ways in which label-references are used Oct 23 20:30:23 Thanks! Oct 23 20:30:54 Well, I was getting some output with the PRU on the spi example and then my BBAI died, literally Oct 23 20:31:05 ... Oct 23 20:31:34 Not sure what happened, but I think it is toast. The VDD_5V is present but there is no VDD_3V3 Oct 23 20:31:43 The power light won't even come on, weird Oct 23 20:31:46 yikes Oct 23 20:33:08 sounds like it might be the equivalent of the power led blip of doom on the BBB... i.e. during power-up the PMIC detects overcurrent and shuts down again Oct 23 20:34:35 Does removing the power led fix that problem on the BBB? Oct 23 20:34:43 lol no Oct 23 20:36:15 the power led on the AI just indicates the 3.3V is up btw Oct 23 20:37:35 Yeah, it looks like it is tied directly to the 3.3V rail. Oct 23 20:37:41 it is Oct 23 20:43:00 I checked the 1.15V rails and the 1.35V rails (easy to get to) and they are both working, weird... Oct 23 20:43:48 wait what Oct 23 20:44:26 the pmic should definitely never just leave *some* supplies on Oct 23 20:45:00 what's the level on TP11 ? Oct 23 20:45:59 How do I find that? Oct 23 20:47:04 no idea, but never mind anyway... I can't find whether it's active-low or active-high, and it's an open-drain output but no pull-up (just connected to the testpoint) Oct 23 20:58:48 Well, I don't think I was doing anything that crazy. I could have possible shorted a pin to ground, but I would think that would only kill the processor and not the PMIC... Oct 23 20:58:57 is the pmic a TPS6590377 like the schematic says or actually its replacement the TPS6590379 ? Oct 23 20:59:19 I don't see a reason to assume the pmic got killed, most likely it is indeed the processor Oct 23 21:01:39 Not sure, it says TPS659037, OTP 97 1.3, 96AEF8W G2, G1 whatever that means... Oct 23 21:02:16 otp 97 is the TPS6590379 Oct 23 21:11:44 lol if I'm understanding the OTP defaults for the pmic correctly, a short-circuit detected on one of the supplies might actually cause a power-cycle rather than a power-off because it generates an interrupt that's unmasked by default and which whose assertion is an ON-request Oct 23 21:12:20 which would explain why other supplies would remain on even if the 3.3v fails to come up (e.g. due to short) Oct 23 21:13:13 I don't suppose you have a scope around, to check one of the supplies that you noticed to be up to see if it's actually periodically cycling briefly? Oct 23 21:13:27 Where do you find the OTP defaults? Oct 23 21:13:33 I do, let me try it... Oct 23 21:13:36 http://www.ti.com/lit/ug/sliu011f/sliu011f.pdf Oct 23 21:14:12 zmatt: fyi, there was a big rush on X15 boards after the AI launch. came while we are switching suppliers from PTI to Seeed. Oct 23 21:14:45 trying to think the next step for u-boot debug. Oct 23 21:15:25 jkridner: currently u-boot seems to configure pins that are not even remotely right for the BBAI... my guess would be they're pinmux for the am572x-evm Oct 23 21:16:00 hunter2018[m]: maybe also measure the 3.3v to see if there's any activity at all Oct 23 21:16:11 hmmm.... I thought my version had a structure based on BBAI. Maybe I should rebuild it. Oct 23 21:16:58 So, just measured them. The 1.15V and the 1.35V rails look rock steady. And the 3.3V rail looks rock steady, just at 0V instead of 3.3V :) Oct 23 21:17:05 well I haven't checked the source code, I meant whatever u-boot is in hunter2018[m]'s BBAI Oct 23 21:17:10 They aren't cycling at all. Oct 23 21:17:18 hunter2018[m]: hum Oct 23 21:18:56 that's so strange Oct 23 21:22:08 the pmic monitors every SMPS for under/overvoltage and overcurrent, so it knows the 3.3V (SMPS9) isn't up... I don't understand why it would just sit there and leave some other supplies enabled Oct 23 21:22:28 and if it's really solidly 0V then it's not even trying to power it Oct 23 21:22:56 maybe measure the 3.3V while applying power? (trigger on rising edge not too far above 0V) Oct 23 21:24:25 a short inside a chip is not going to have such low resistance that it would be able to keep the 3.3V firmly at 0V given that the pmic can supply 1A on that rail Oct 23 21:25:27 and of course the question is still... wtf happened in the first place Oct 23 21:26:12 iirc you're also not the first whose bbai mysteriously died, but I'd need to dig through chat logs to be sure I remember that correctly Oct 23 21:29:41 Ok, so the 3.3V rail does have a blip when I first power it up. It jumps to about 870mV and stays there for 3ms before dropping back down to 0V. Oct 23 21:29:57 ouch Oct 23 21:30:36 that sounds compatible with the hypothesis of a short on the 3.3V Oct 23 21:31:08 it's just a bit weird that this causes the pmic to just shut off that single supply instead of powering down entirely Oct 23 21:31:34 that might be ill-chosen OTP programming Oct 23 21:32:30 hunter2018[m]: when this happened, were you still operating without cape_pins or had you restored it already by then (to suppress the clearly bogus pinmux) Oct 23 21:33:54 I wasn't still operating without cape-pins. I had restored it and I could see that both the SPI output and the PRU output were working right before it died. Oct 23 21:34:30 so it basically just happened randomly Oct 23 21:35:02 that's concerning Oct 23 21:36:07 Yeah, if I did do something wrong, it could have been that I shorted something when probing with the oscilloscope probes, but I really don't think I did. Oct 23 21:36:19 Well, I think I Oct 23 21:36:42 *Well I think I've done enough damage for one day :) I'll pick this up tomorrow. Good thing we ordered 4 of them :). Still have 3 more shots... Oct 23 21:37:13 lol... we also have a small cemetary of beaglebones... though BBBs are a bit cheaper than BBAIs Oct 23 21:38:58 Yeah, it's like I killed 2.3 BBBs in one moment 😓 Oct 23 21:39:14 and I don't think I've ever killed a BBB with a short or overcurrent Oct 23 21:39:31 the usual way to kill one is overvoltage... e.g. a 7V supply wire accidently landing on top of a BBB Oct 23 21:43:16 Lol... You work for a company that does audio stuff with beaglebones right? I think you told me that once iirc. Oct 23 21:44:19 comparing the autogenerated from the manually generate files is a real pain. Oct 23 21:44:48 zmatt: already got some extraction tools to help the comparison? Oct 23 21:47:55 hmmm.... https://github.com/beagleboard/beaglebone-ai/blob/master/SW/u-boot/pinmux/Hamster.pinmux is really old and incomplete. Oct 23 21:49:07 hunter2018[m]: https://dutchdutch.com/ Oct 23 21:51:24 jkridner: hmm, what do you want do compare with what? Oct 23 21:53:13 Does anyone know if there is a straightforward method to remove the bluetooth functionality of the AI model at the hardware level? Oct 23 21:53:26 ... why would you want to do that Oct 23 21:54:25 Some work locations do not allow any bluetooth devices of any kind Oct 23 21:54:33 but they do allow wifi? Oct 23 21:54:53 In some cases Oct 23 21:54:54 wifi/bt is one chip Oct 23 21:55:14 I could live without both if that worked Oct 23 21:56:44 cronjob: you could depop the brcmfmac module or just get an x15 which doesn't have wifi/bt Oct 23 21:58:15 removing the entire wifi/bt IC is definitely the surest way... alternatively it looks like you can easily cut power to some of its supplies but you'd need to check the datasheet to see what the consequences are of doing so, and you'll need to make sure the corresponding pins on the am57xx don't get muxed (at least not to output mode) Oct 23 21:59:06 or you could cut communication traces if they happen to be at the surface (which would allow cutting BT while keeping wifi).. you'd need to check the pcb design Oct 23 21:59:34 Do you have any idea if it would be as simple as Oct 23 21:59:47 but if someone is going to believe you when you say you disabled the BT, why wouldn't they believe you the same if you disable it in software (e.g. by removing the BT node from the devicetree) Oct 23 21:59:49 removing the chip, or would the device complain afterwards? Oct 23 21:59:50 bluetooth is usart, so you could cut those 2 lines.. Oct 23 22:00:09 it would complain, but wouldn't break anything Oct 23 22:00:14 ^ Oct 23 22:00:28 and you can fix the complaint by making a custom DT Oct 23 22:00:38 (best thing about Device Tree's.. Hardware doesn't care if it's not longer there..) ;) Oct 23 22:01:05 vs the old board files, which would blow up and hardlock on missing stuff.. Oct 23 22:01:20 When we buy computers, they give us an envelope with the bluetooth parts inside to prove it was removed usually Oct 23 22:01:44 what's the point of this bizarre requirement? Oct 23 22:01:47 Unfortunately, the X15 appears to be unavailable from distributors, as it is no longer produced Oct 23 22:02:02 mouser has 491 on order, expected in less than a month Oct 23 22:02:10 cronjob: it's being switched to a new cm, it'll be back soon. Oct 23 22:02:26 https://www2.mouser.com/ProductDetail/?qs=mAH9sUMRCtul7OWq6qLH4g%3D%3D Oct 23 22:03:30 Ah, thanks, I was looking at the link from the beagleboard website https://www.mouser.com/ProductDetail/Beagleboard-by-PTI/BeagleBoard-X15 Oct 23 22:04:32 Yeah, once PTI stopped production, everyone just deleted the product page for it, instead of point to the new seeed model.. Oct 23 22:05:04 mouser links to the new one Oct 23 22:05:42 unless you click on cronjob 's link, which was the old product page.. Oct 23 22:05:52 (that should have been redircted..) Oct 23 22:05:55 oh Oct 23 22:06:06 weird Oct 23 22:06:07 Mine just came from here http://beagleboard.org/x15 Oct 23 22:06:28 jkridner: maybe time to update some links? :) Oct 23 22:06:36 Anyhow, thanks for the guidance Oct 23 22:07:18 jkridner: two people today here thought the x15 was discontinued... imagine how many more there are that *don't* come here Oct 23 22:07:27 k. Oct 23 22:07:43 Arrow looks ok, but no stock. probably should remove until they reorder. Oct 23 22:08:29 we've got the new seeed page up, but the old pti is still the link from the org.. Oct 23 22:10:29 https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-embedded-mcu-dsp/786?k=&pkeyword=&sv=0&pv983=402976&pv506=314813&sf=0&FV=-8%7C786%2C-1%7C1597&quantity=&ColumnSort=0&page=1&pageSize=25 is an ugly link Oct 23 22:10:41 rcn-ee[m]: where should I link to? Oct 23 22:11:04 use this one: https://www.digikey.com/products/en?keywords=1597-102110288-ND Oct 23 22:11:08 https://www.digikey.com/products/en?keywords=1597-102110288-ND ? Oct 23 22:11:11 :-D Oct 23 22:14:55 should be fixed now Oct 23 22:15:21 zmatt: rcn-ee[m]: thanks Oct 23 22:25:06 Cool, looks good. Thanks again. **** BEGIN LOGGING AT Thu Oct 24 01:30:55 2019 Oct 24 01:49:50 @jkridner: Sir, I see there is a test-runner needed on the source side of things here: https://github.com/beagleboard/cloud9-examples. Oct 24 01:49:59 If you need me to test things, let me know. Oct 24 01:50:19 For instance, please let me know where to start. Oct 24 01:51:31 I replied on that page on github. I will check back periodically. Oct 24 02:00:24 On the github repo, it states nightly-ish builds. Is this for the source or for other aspects relating to the source and the bone-linux distros? Oct 24 02:06:29 I can use Selenium or some other type. Who knows? Let a brother know if you are getting desperate. I like testing source to see if it works or not (so far). Oct 24 02:18:15 https://www.seleniumeasy.com/python/pytest-run-webdriver-tests-in-parallel is something I found. I can use pytest w/ this Selenium tester. I think there are many "apps" for Selenium. I just need to get it up and running. Oct 24 02:18:16 ... Oct 24 02:18:23 So, please let me know when you have time. Oct 24 02:20:16 Oh! It works w/ JavaScript too. So, bonescript will not be left behind. Oct 24 02:28:01 Well, node.js. This is a good thing. Oct 24 02:34:55 I will just set it up and provide my first test. Then, you can tell me if you can use me. **** ENDING LOGGING AT Thu Oct 24 02:59:57 2019