**** BEGIN LOGGING AT Thu Oct 24 02:59:57 2019 Oct 24 04:46:48 rcn-ee[m]: so what's the change they did for the console, a pull-down on "UART1_RX" (the input to the buffer that would otherwise remain floating) Oct 24 04:47:51 lol, so there's no pull up or down on that floating input in the schematic, but there *is* a pull-up on the UART1_RXD pin of the am572x (which is pointless since it's tied to the buffer output) Oct 24 05:19:42 The build is broken. Off to find another testing interface. Oct 24 13:05:09 Yello Oct 24 13:05:23 Invalidating TLB clears stack - any ideas ? go... Oct 24 13:12:45 ?? Oct 24 13:13:19 no?? Oct 24 13:15:02 well, let's say, if he unmapped or remapped his own stack, then it'll be gone once TLBs are invalidated ;) Oct 24 13:32:02 With the Beaglebone AI, can you use https://github.com/beagleboard/am335x_pru_package for PRU UIO and PASM assembler? Oct 24 13:32:37 I'm pretty sure I was using PASM from this repo and it was working on the BBAI, even though it says it is for the am335x... Oct 24 13:37:31 I assume that it is fine because the PRUs are the same pretty much on both the BBAI and the BBB, except that there are 4 on the BBAI. Oct 24 13:43:26 zmatt: they stuck a resistor between gnd and the other pin.. ... yeah... Oct 24 13:46:04 is it possible to control 24v in beagle bone black?? Oct 24 13:47:14 Survivor: sure... with a relay cape: https://github.com/beagleboard/capes/tree/master/beaglebone/Relay Oct 24 13:48:00 here's a better picture: https://www.digikey.com/products/en/development-boards-kits-programmers/evaluation-boards-expansion-boards-daughter-cards/797?k=relay%20cape Oct 24 13:50:31 In my project i have 100/100 inputs/outputs... all are 24v dc.. which is the recomended bord model number?? Oct 24 13:51:19 Survivor: wow, yeah... best to design something.. Oct 24 14:34:39 Another quick question, so I cloned the BeagleBoard-DeviceTrees git repo and I'm using the latest BBAI debian image (uname -r returns 4.14.108-ti-r113) Oct 24 14:35:30 To get the correct .dts files I need to checkout the v4.14.x-ti branch of this repo right? Oct 24 14:37:02 hunter2018: yes Oct 24 14:37:19 Which means from the repo I just run git fetch, then git checkout v4.14.x-ti right? Oct 24 14:37:25 Thanks! Oct 24 14:44:01 So how does this work, it looks like the most recent linux kernel is v5, and the most recent Debian version is 10. So how does the most recent BBAI image end up with linux kernel v4.14 and Debian version 9? I'm assuming it's because it takes a while to modify the base Debian distro to work with the Beaglebone and therefore it doesn't update instantly right? Oct 24 14:44:37 Also, they are kind of independent right? Like you can have a new version of Debian and an old version of the Linux kernel can't you? Oct 24 14:58:40 Flashing the bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img in my BBB results in the BBB looping somewhere. After the penguin, the screen shows the cursor blinking a couple of time and then going all black forever. Ethernet port blinking, heartbeat led beating, but nothing else. Oct 24 14:58:50 Am I the first known case? Oct 24 15:00:14 I was able to run that version from the SDCard, though. Oct 24 15:03:51 zmatt rcn-ee[m]: i'm still working on the updated u-boot default pinmux. we'd kinda decided to enable some eHRPWM signals on the cape header, but I'm worried what their default is. Do you know if the signals drive just because the pinmux is enabled or do we need to also enable the PWM module in some way before it starts to drive the signals? Oct 24 15:04:26 hmm there are some gotchas with those kinda things Oct 24 15:04:53 veremitz: indeed. just default them to gpio mode? Oct 24 15:05:13 just would be nice if there were some more fun peripherals to play with without needing to hack dt. Oct 24 15:05:49 I suspect zmatt would know .. :) Oct 24 15:05:57 we'llsee when he pops in next :D Oct 24 15:13:11 jkridner: it looks like the pwm's on the bbai are like the am3, they need both nodes enabled before they ouput: https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BBAI_BB-BONE-LCD7-01-00A3.dts#L181-L195 Oct 24 15:14:45 before they toggle or before they drive? Oct 24 15:15:43 I'm not trying to get some thing to work right now, I'm trying to keep boards from blowing up. :-D Oct 24 15:17:32 Quick question, I made a new .dtb file and modified uEnv.txt, now my BBAI won't boot at all. Is there a way to revert the changes? Oct 24 15:17:58 Perhaps I could boot off the SD card, fix my uEnv.txt file on the on board flash? Oct 24 15:19:00 hunter2018: correct, boot from microsd, here is small image: https://rcn-ee.net/rootfs/bb.org/testing/2019-10-21/stretch-iot/am57xx-debian-9.11-iot-armhf-2019-10-21-4gb.img.xz Oct 24 15:22:02 how could i try to get why my BBB is'nt working right? Oct 24 15:24:12 Parduz: do you have a serial cable to plug into the J1 header? Oct 24 15:24:24 nope Oct 24 15:24:37 never needed that 'til today. Oct 24 15:24:45 https://elinux.org/Beagleboard:BeagleBone_Black_Serial Oct 24 15:24:58 actually is the fisrt time i see an image failing Oct 24 15:25:12 which image did you try? Oct 24 15:25:27 bone-debian-9.9-lxqt-armhf-2019-08-03-4gb.img Oct 24 15:26:18 is it doing anything? led's blinking? Oct 24 15:27:49 the BBB is looping somewhere. After the penguin, the screen shows the cursor blinking a couple of time and then goes black for 3 sec. Repeat forever. Ethernet port blinking, heartbeat led beating, other two blue leds blinking randomly Oct 24 15:28:20 how are you powering the board? Oct 24 15:28:27 (starts image download) Oct 24 15:28:36 with a power supply Oct 24 15:28:53 5v 2a+? Oct 24 15:29:00 yep Oct 24 15:29:54 yesterday we flashed 8 BBB with an image i thought was good (BBB-blank-debian-9.9-lxqt-armhf-2019-05-27-4gb.img), zmatt suggested to update to newer one Oct 24 15:30:31 so i tried with that image today. It runs booting from the SDCard, but flashing does'nt works. Oct 24 15:30:49 So now that I'm booted up using the sd card, how do I access the on board flash to change my uEnv.txt? Oct 24 15:31:07 Parduz: are they rev B or C BBB's? Oct 24 15:31:21 hunter2018: mount the 2nd mmc device.. Oct 24 15:31:49 should be C Oct 24 15:32:47 but i can't remember where to look (iƬ've not the boxes here). But the older one i have are RevA, and i've never seen a B, so i can't go wrong. Oct 24 15:37:10 rcn-ee: Which one of these would I mount? Oct 24 15:37:30 I tried mmcblk0p1, but I think that's actually the sd card I'm running off of now Oct 24 15:37:51 hunter2018: lsblk Oct 24 15:37:51 https://pastebin.com/raw/aCisawzp Oct 24 15:38:24 this one: /dev/mmcblk1p1 Oct 24 15:38:59 So I tried mmcblk1 and that didn't work. Does the p1 mean partition 1? Oct 24 15:39:36 That worked! I'm in... Oct 24 15:40:59 And after removing the offending dtb from uEnv.txt it is booting up correctly. Oct 24 15:48:02 rcn-ee[m] zmatt: I'm finding some odd power domain conflicts I'd missed before. Oct 24 15:48:43 pin tool claims that vddshv3 and vdda_hdmi should match. Oct 24 15:48:44 oh fun.. ;) Oct 24 15:50:16 http://e2e.ti.com/support/processors/f/791/t/582944?AM5728-Pinmux-Tool-voltage-conflict-question Oct 24 15:50:53 "You may ignore this particular warning. It's a bug in the tool. We are looking into it in will be fixed in future versions. Please follow voltage domain configuration as suggested in the Data Manual." Oct 24 15:51:35 rcn-ee[m]: are you trying that image? Oct 24 15:53:22 Parduz: finally flashed my microsd.. Oct 24 15:53:54 vdda33v_usb1 (3.3V) and vdda_usb1 (1.8V) generates a similar conflict in the tool. Oct 24 15:54:24 asked 'cause then i'll wait to hear your result. Oct 24 15:54:50 downloading the update. Oct 24 15:56:28 Parduz: looks fine: https://gist.github.com/RobertCNelson/2981bd98704a61c13c8cf01cf7bb501d Oct 24 15:57:38 duh Oct 24 15:57:52 not fixed in 4.0.1537 of the pinmux tool. Oct 24 15:58:10 did you boot from the MicroSD? Oct 24 15:59:12 also shows up on the cloud version. Oct 24 15:59:42 or flashed it? Oct 24 16:10:48 rcn-ee[m] zmatt: for your review: https://github.com/beagleboard/beaglebone-ai/commit/103e920fc2c10f95e5259362a7f7d04eb8d46740 Oct 24 16:46:03 jkridner: those sound like favourite kinds of heisenbugs :D Oct 24 17:01:53 So with the beaglebone-ai, the default uEnv.txt doesn't use any device tree at all right? Just the uboot defaults since #dtb= is commented out Oct 24 17:13:49 hunter2018[m]: there is a default dtb, am5729-beagleboneai.dtb Oct 24 17:13:56 the dtb setting is an override. Oct 24 17:55:14 Thanks! Oct 24 18:07:30 Ahh, I think I may have been having boot issues because I set dtb=/boot/dtbs/4.14.108-ti-r113/am5729-beagleboneai-uio.dtb Oct 24 18:07:48 It should just be dtb=am5729-beagleboneai-uio.dtb Oct 24 18:08:21 I'm guessing it was looking for dtb=/boot/dtbs/4.14.108-ti-r113/dtb=/boot/dtbs/4.14.108-ti-r113/am5729-beagleboneai-uio.dtb Oct 24 18:52:40 zmatt: I finally got your py-uio spi test working on the BBAI. It says Test passed! Oct 24 18:53:05 However, if add one line that changes the speed to 1MHz then I get 125 bit errors. Oct 24 18:54:46 Here is how I am changing the speed: https://pastebin.com/raw/HkiKT8MT Oct 24 19:36:45 wait so it works at higher speed but not lower speed? Oct 24 19:37:15 Yeah, exactly Oct 24 19:37:51 It could be the process of setting the speed is messing something up? Oct 24 19:37:56 If I just let it run at default it works fine. Oct 24 19:38:26 you can try lowering the speed using DT instead to test that hypothesis... but it sounds odd to me Oct 24 19:39:40 jkridner: as for ehrpwm, I'm 99% sure it'll enable the outputs the moment you change pinmux to ehrpwm Oct 24 19:39:55 so I recommend against making that the default Oct 24 19:40:31 most pwm applications are probably insensitive to a few nanosecond glitch so I don't see a huge reason to configure that pinmux in u-boot, doing it in DT should be fine Oct 24 19:51:11 I want to use P9.11a/P9.13a as UART4RX/TX on the BBAI. Before on the BBB the serial port that mapped to these pins was at /dev/ttyO4, which device is it mapped to now? Oct 24 19:52:32 Also, to use the python serial.Serial("/dev/ttyO4") function that worked on the BBB is there anything I need to do more than put P9.11a/P9.13a into pin mode 4 (uart 4 rxd / uart 4 txd)? Oct 24 19:53:09 I guess I'm wondering if I need to enable any kind of driver in the device tree in the same way I did to get SPI working on the BBAI. Oct 24 19:53:14 so those pins are considered uart5 by the TRM, &uart5 in DT, uart4 in my spreadsheet (hence show-pins), and /dev/ttyS4 (with compat symlink /dev/ttyO4) by the kernel Oct 24 19:53:42 yep, &uart5 { status = "okay"; }; Oct 24 19:55:06 which is also the node to which you'd attach the pinmux for the uart Oct 24 20:02:13 hunter2018[m]: https://pastebin.com/raw/Rg0i0FBh Oct 24 20:06:08 hunter2018[m]: have you tried whether lowering the spi-max-frequency in the spidev node in DT works? I'm still quite puzzled by it. can you try print( txdata.hex() ); print( rxdata.hex() ); print( errdata.hex() ) Oct 24 20:08:15 and then maybe a few runs (to see if there's any sort of pattern) Oct 24 20:13:33 hunter2018[m]: I just saw your earlier question about versions: debian 10 (buster) is available and I do run it, but I think for the official images stable/well-tested is preferred over "latest". as for the kernel, the TI series kernels are only available for LTS releases, so 4.19 was the most recent and presumably there will be a 5.4-ti kernel series Oct 24 20:14:14 and yeah you can mix&match kernel version and distro version pretty freely Oct 24 20:14:25 within some limits of sanity Oct 24 20:18:54 jkridner: vddhv3 includes various HDMI-related signals (hpd, cec, ddc scl/sda) so maybe that's why Oct 24 20:20:07 I can imagine if it grouped those together with the actual hdmi signal (which uses vdda_hdmi) that it can believe those need to use the same voltage Oct 24 20:21:12 wait what Oct 24 20:21:35 ah nm, got confused for a sec Oct 24 20:22:53 I really hate schematics like these where everything is shredded into tiny bits connected by named nets... my coworker used to make schematics like those too until I had a serious talk with him Oct 24 20:23:46 just connect shit with wires ffs so I can see at a glance how things connect Oct 24 20:29:04 jkridner: so yeah, the assumption all lines of an interface belong to the same power domain, while often true, is already wrong in this case (hpd, cec, and ddc are 5V signals) and moreover there's a level shifter for those signals anyway Oct 24 20:43:57 zmatt: Cool! Thanks for the device tree additions! Oct 24 20:44:17 I changed the max frequency to 1MHz in the DT node, so I'll let you know if that works Oct 24 20:45:02 jkridner: PinmuxConfigSummary.csv is showing vddhv1 being at 1.8v instead of 3.3v Oct 24 20:49:05 zmatt: clear as mud?! Oct 24 20:56:42 veremitz: ? Oct 24 20:56:52 pins, signals and power grids Oct 24 20:56:58 you haven't mentioned Clocks yet ;D Oct 24 20:57:01 oh and muxes. Oct 24 20:59:53 jkridner: you're missing pull on most pins. I'd suggest keeping all pulls at their reset default unless a good reason has been determined to change it for a pin Oct 24 21:02:21 (the default pull is down on most expansion header pins, except: P8.03-06, P8.20-25, and P9.23-24. there is a pull-up/down conflict on P9.17 and P9.26 that should be resolved Oct 24 21:02:24 ) Oct 24 21:04:33 I'm going to be out for a few days, but thanks for all the help zmatt! The fact that I have one example working gives me hope that I can get my BBB PRU based ADC board working on the BBAI. Oct 24 21:05:17 Never having dealt with device trees (being spoiled by the BBB) I didn't know just how much I didn't know :) Oct 24 21:06:35 hunter2018[m]: no results? Oct 24 21:06:45 regarding the spi test Oct 24 21:10:23 Unfortunately I'll have to get to that next week. Oct 24 21:10:37 ok Oct 24 22:11:55 jkridner: so, here's the pinmux you linked to but restricted to the expansion header and presented in a more human-friendly form: https://docs.google.com/spreadsheets/d/e/2PACX-1vSB0SmXxNCxdazDYFF9x55__ks2zxsuh8-AZYl7kkCSIJptsBHP02ZPD2lu-XS6JTe8-uWtnhnWOSwz/pubhtml?gid=1887626825&single=true Oct 24 22:13:26 a bunch of pins are left unmuxed, which is not a problem in itself but it's a departure from what you did in cape_pins_default... it would probably be more useful to have pins default to gpio mode when available Oct 24 22:14:30 for almost every pin you did configure you've disabled the internal pull-up/down, which is obviously not good (the "Initial" column is default pull-up/down, the "Pull" column is the one you configured) Oct 24 22:16:50 a bunch of pins are outputs by default (pwm pins, uart txd, some spi pins probably) Oct 24 22:18:51 (I'd *assume* i2c pins are high-impedance when the i2c controller is disabled and uninitialized) Oct 24 22:26:05 for most signals I'm not sure they'd be very sensitive to a few nanosecond glitch anyway... i2c *maybe* Oct 24 22:34:55 i2c isn't that fast, and with a pull-up on the lines, you probably wouldn't see much in practice. Certainly not a START condition I'd hope :D Oct 24 22:35:25 hopefully it would get glitch-filtered yeah Oct 24 23:14:04 anyone know where the tools for converting models to TIDL format is located? Oct 24 23:14:43 plenty of references to a tool but not much details on where to get it. there is something alluding to it being buried in another SDK Oct 24 23:18:50 sounds eerily plausible :/ Oct 24 23:20:01 before I start downloading 2342441324123423 different SDK to look for.... :D Oct 24 23:20:21 so far the models available for TIDL are pretty boring Oct 24 23:22:46 once opencv and other crap has been stripped from the examples, things look somewhat reasonable... though a 300mS to process a ~200x200 image on a single eve seems a bit troublesome Oct 24 23:23:15 adding more eve/dsps doesn't seem like it will bring it to 30fps Oct 24 23:26:24 I really wish lxqt wasn't shipped Oct 24 23:30:54 is this right - no cpuidle driver on the BBAI? Oct 24 23:59:52 a constant 4W consumption seems high Oct 25 00:50:33 So, should I set up the test suite on a Debian Distro and keep checking that distro for if the image and files run on it w/out error and then report? Oct 25 00:52:09 e.g. for a test-runner on these builds and source on https://github.com/beagleboard/cloud9-examples? Oct 25 00:58:37 I guess what i am asking is this...should I make sure I have a Beagleboard.org image on the hard drive of what source I am testing so I can record? Oct 25 01:01:25 ds2: I made a quick util that checks if the cortex-a15 subsystem is configured to permit entering retention (the lowest state that doesn't require any save/restore effort) and if not, configures it as such... https://liktaanjeneus.nl/bbx15/omap5-cpu-prcm.tar.gz Oct 25 01:02:23 on kernel 4.14.108-ti-r120 it was not permitted to enter any sort of low power state, and running this util made my cpu temp go down quite significantly Oct 25 01:05:25 I haven't checked whether SR3-APG is enabled Oct 25 01:25:00 updated the utility to allow make changing the low-power state optional (see --help) Oct 25 01:25:12 *to make Oct 25 01:32:11 there is evidently code for managing mpuss prcm => https://github.com/beagleboard/linux/blob/4.19/arch/arm/mach-omap2/omap-mpuss-lowpower.c Oct 25 01:32:40 originally written for the omap4, but it does have code for omap5/dra7 as well Oct 25 01:32:45 but clearly it ain't working Oct 25 01:33:18 even merely selecting "inactive" mode causes noticable drop in cpu temperature (though nowhere near as much as "retention") Oct 25 01:34:21 I'll leave it at inactive for a bit, let's see where it stabilizes Oct 25 01:47:04 let me try Oct 25 01:47:08 it isn't zip! Oct 25 01:47:11 zipped Oct 25 01:47:46 ? Oct 25 01:48:02 oh lol Oct 25 01:48:04 my bad Oct 25 01:48:15 I'll rename it to .tar Oct 25 01:48:47 no I better just gzip it to keep the link the same Oct 25 01:48:59 there Oct 25 01:49:32 no biggie Oct 25 01:49:45 nothing running file on it didn't expose :D Oct 25 01:50:34 I generally use tar xf anyway since it autodetects compression Oct 25 01:50:43 u must have a newer version Oct 25 01:50:45 mine doesn't Oct 25 01:50:56 oh wow I feel like tar has done so for ages Oct 25 01:52:19 not that big of a drop Oct 25 01:52:33 just dropped about 50mA or so on the 5V side Oct 25 01:53:06 860mA @ 5V is a lot for an idle system...now it hovers around 800-760mA @ 5V Oct 25 01:53:19 but heatsink wise, it is a big diff :D Oct 25 01:54:03 yeah I didn't monitor power, just temperature Oct 25 01:54:21 got a USB-C inline monitor on it Oct 25 01:56:07 your thing must be stomping on the same registers used to disable CPUs Oct 25 01:56:18 power shot back up when I turned off cpu1 Oct 25 01:56:54 my util won't stomp cpu-off settting, but the kernel will stomp what I did when you turn a cpu on Oct 25 01:57:19 echo 0 > online took longer and the power shot back up Oct 25 01:57:26 after that running ur util made no difference Oct 25 01:57:38 cpu off is power state 0 (which you can't set with my utility, nor will it touch a core in power state 0 ) Oct 25 01:57:41 odd Oct 25 01:57:41 what does it print? Oct 25 01:57:49 nothing, just took a while Oct 25 01:57:55 my util I mean Oct 25 01:58:16 core 0 pwrctrl 0x00030105 pwrstat 0x01000037 clkstctrl 3 lostcontext 0x000 standby 0 wugen 0x07 Oct 25 01:58:20 same values for core 1 Oct 25 01:59:05 yeah that looks correct for allowing the core to enter retention, and it confirms that it has in fact entered retention since the last time you ran the util Oct 25 01:59:45 msb of pwrstat is lowest power state reached since last time Oct 25 01:59:54 oh nice Oct 25 02:01:01 eh? Oct 25 02:01:05 first time since power on - Oct 25 02:01:12 core 0 pwrctrl 0x00030107 pwrstat 0x03000037 clkstctrl 3 lostcontext 0x101 standby 0 wugen 0x07 Oct 25 02:01:17 for retention Oct 25 02:01:45 this looks like expected output for the first dump after power-on reset Oct 25 02:02:02 doesn't the 37 ment it did go into retention before hand? Oct 25 02:02:15 no, 3 = on, 2 = inactive, 1 = retention, 0 = off Oct 25 02:03:24 oh MSB...blah Oct 25 02:03:30 I was reading LSB :D my bad Oct 25 02:03:54 lsb is current power state Oct 25 02:04:26 for some reason I don't I've never actually caught core 1 being in rentention... which actually puzzles me a bit Oct 25 02:04:36 or either core I mean Oct 25 02:05:12 I'd kinda expect the core on which my util isn't running to usually be in WFI on an idle system Oct 25 02:06:56 lemme see if I can check whether SR3-APG ("mercury") is enabled Oct 25 02:11:05 it is Oct 25 02:11:23 seeing some very odd behavior after a power cycle... going to leave it off for a while incase something isn't resetting the PRCM Oct 25 02:11:42 oh I have no idea what effects this might have of course Oct 25 02:12:04 it shouldn't be able to cross power cycles unless the EE's f'ed the power on reset Oct 25 02:12:52 oh after a power cycle... no, in fact it shouldn't survive even a warm reset (though the bbai and bbx15 never warm-reset anyway, all resets are cold) Oct 25 02:14:29 yep, powering off a few mins fixed it Oct 25 02:14:46 that sounds disturbing if true Oct 25 02:14:58 what "odd behaviour" were you seeing? Oct 25 02:15:08 was drawing 900-950mA doing the same thing before... after there few minutes of power off, it is doing the 760-800mA thing after running ur utility Oct 25 02:15:15 w/--retention Oct 25 02:15:26 ehh Oct 25 02:15:43 yes, the power draw changed despite doing the same thing Oct 25 02:15:49 only difference is I turned it off for a few mins Oct 25 02:26:50 so... this is the bits I found regarding retention mode and hg (marketing name "SR3-APG")... and it makes everything clear as mud => https://pastebin.com/if0AjBjK Oct 25 02:35:56 10 degrees difference in cpu temp between "on" and "retention" (after giving it time toe stabilize) on my bbx15 when idle **** ENDING LOGGING AT Fri Oct 25 03:00:03 2019