**** BEGIN LOGGING AT Mon Nov 04 02:59:58 2019 **** BEGIN LOGGING AT Mon Nov 04 14:32:18 2019 Nov 04 14:57:25 zmatt: I need to catch up on logs, but can you point to the latest version of your spreadsheet? I still had some confusion based on what I *thought* I had the pins set to . Nov 04 14:59:57 hmmm.... seems the sheet is updated since I last looked. Nov 04 15:00:38 rcn-ee[m] zmatt: for I2C5/I2C4, what do you think about having both I2C pins and GPIO pins with pull-up enabled? Nov 04 15:00:56 er, for I2C4, PRU pins. Nov 04 15:06:49 looking over the latest sheet, I can't say it is 100% consistent, but it seems to be reasonable/functional. Nov 04 15:07:03 I'm thinking it actually reflects my previous commits now. Nov 04 15:09:57 nice, I just tried to buy a BBAI from okdo but it's telling me my address is invalid (it really isn't :P ) Nov 04 15:10:49 you have to go to the very bottom of the page and select the correct country. Nov 04 15:10:53 it is very odd in that way. Nov 04 15:11:13 correct country is already selected there Nov 04 15:11:25 oh? that's been the only problem I've had with it. Nov 04 15:11:39 and it has been a real pain, claiming invalid addresses otherwise. Nov 04 15:12:08 I think I recall them having some problems with Scandinavian countries, if you are in one of those. Nov 04 15:12:21 I'm not, I'm in the Netherlands Nov 04 15:12:50 which country are you using from their site? Nov 04 15:13:01 the Netherlands :P Nov 04 15:13:17 ah, they have Netherlands as one of their 7 options. Nov 04 15:13:27 yep, the form itself is also in dutch Nov 04 15:13:49 well, you'd think they'd accept a good address. :-/ Nov 04 15:14:09 it's specifically showing an error from paypal Nov 04 15:14:15 PayPal error (10727): The street address in your shipping address is not valid. Please double-check your shipping address and try again. Nov 04 15:15:08 oh... so paypal or paypal integration error? Nov 04 15:15:21 not necessarily okdo's mess up. Nov 04 15:15:50 i love that they have an R-Pi on their "Industrial" page. Nov 04 15:17:41 nah they fucked up Nov 04 15:17:57 they have an optional "Apartment/suite/etc" field, which I left blank since it doesn't apply Nov 04 15:18:05 I now just filled in something there, and now it works Nov 04 15:21:32 it seems like that line is being submitted to Paypal as "address_1" while the actual street address field is submitted as "address_2", and paypal isn't happy about a blank address_1 Nov 04 15:21:54 okdo however allows the first field to be blank and disallows the second field to be blank Nov 04 15:59:28 trying to flash my image in the BBB.... the script boots but then: Nov 04 16:00:00 "could not reliably determine source and destination. We need to stop here." Nov 04 16:00:06 What should i look for? Nov 04 16:05:57 Parduz: uhh what? Nov 04 16:06:39 Parduz: more context please, how did you create the image, what are you doing to try to flash it exactly, and can you provide full log output? Nov 04 16:08:41 the image is the IOT that i'm tampering from a week with your help Nov 04 16:09:11 uncommented the last line in boot/uenv.txt as usual Nov 04 16:09:24 trying to ssh to get the loh Nov 04 16:09:25 log Nov 04 16:10:07 pretty sure you can't ssh into a flasher image Nov 04 16:10:25 since the system never really boots in any meaningful way Nov 04 16:10:50 yup. so the answer to your last question is "no" Nov 04 16:11:01 no way to capture serial console output? Nov 04 16:11:21 nope Nov 04 16:11:28 it seems a bit odd that this would fail on an iot image, with or without changes Nov 04 16:11:57 i can just add that the last line on the screen says that "we don't know how to reset the led 'cause we're not Nov 04 16:11:58 have you tried powering on with the S2 button held down, to bypass whatever u-boot may be present on eMMC ? Nov 04 16:12:15 a BBB compatible device (sorry for the Enter) Nov 04 16:12:24 uhh Nov 04 16:12:41 i always start flashing booting in that way Nov 04 16:13:47 what does it say the Boot Drive is? Nov 04 16:14:16 root drive identified as [] Nov 04 16:14:20 boot drive is [1] Nov 04 16:14:23 oooookay then Nov 04 16:15:54 oh lol, does the flasher break when the root fs is given as path instead of by UUID ? Nov 04 16:16:15 hmmm it shouldn't I think Nov 04 16:16:37 if the log is saved on the SDCard i can plug it in the PC and read from there the log.... Nov 04 16:16:49 i don't knoe what are you asking :) Nov 04 16:17:05 I'm not really asking you, I was just wondering out loud Nov 04 16:17:06 sorry Nov 04 16:18:25 weird, I don't understand how it can fail to find the rootfs device Nov 04 16:19:48 it should also be printing the kernel parameters, what is the "root" kernel parameter set to? (I'd expect root=/dev/mmcblk0p1 ) Nov 04 16:20:14 just after "Determining root drive" Nov 04 16:20:19 Parduz: do you have a boot log saved to pastebin? Nov 04 16:20:38 rcn-ee[m]: is the log saved to sd card? Nov 04 16:20:51 zmatt: no /proc/cmdline Nov 04 16:21:02 rcn-ee[m]: nope Nov 04 16:21:14 ah nope.. partition is 'ro'.. Nov 04 16:21:17 wtf, no /proc/cmdline ? Nov 04 16:21:22 how? Nov 04 16:21:33 Parduz: can you dump a serial log to pastebin? Nov 04 16:21:41 17:11 <@zmatt> no way to capture serial console output? Nov 04 16:21:41 17:11 < Parduz> nope Nov 04 16:21:57 hdmi? Nov 04 16:22:19 Parduz: are you using a custom kernel? Nov 04 16:22:23 usb port with a ftdi adapter? append the cmdline for that redirect? Nov 04 16:22:33 wait: Nov 04 16:22:54 the BBB is attached to a LCD4 cape (like) but i can plug it on the HDMI Nov 04 16:23:02 neither is useful Nov 04 16:23:17 zmatt: no, the one in the image Nov 04 16:23:21 ... crap i think they are modules, so sadly that would come up to late for console... Nov 04 16:23:23 (about hte kernel) Nov 04 16:24:07 can you remove the LCD4, plug in a serial port to J1? Nov 04 16:24:21 i don't have any serial cable arounf Nov 04 16:24:28 never used it Nov 04 16:24:43 it's something you rarely need, but when you do need it it really sucks to not have one Nov 04 16:25:03 okay, let me know when you get something, kinda a waste of debuggin time. ;) Nov 04 16:25:11 especially anything to do with debugging boot issues, networking issues, or issues with the flasher :P Nov 04 16:25:17 could it be 'cause the initdram i've removed? do the flasher script need them? Nov 04 16:25:33 https://elinux.org/Beagleboard:BeagleBone_Black_Serial Nov 04 16:25:46 Parduz: that would be my guess, though I'm not sure why Nov 04 16:25:51 Parduz: just get a serial cable, no sense in random guess.. ;) Nov 04 16:25:51 maybe it doesn't mount /proc ? Nov 04 16:26:07 rcn-ee[m]: have you ever tested the flasher without an initramfs? Nov 04 16:26:19 initramfs is needed for the flassher.. Nov 04 16:26:40 it bombs right away.. Nov 04 16:28:07 well it failed with the cryptic error that it "Could not reliably determine Source and Destination" Nov 04 16:28:25 give me a moment, i'll flash one and save it to poastebin.. Nov 04 16:28:44 apparently ultimately because it expects /proc to be mounted and doesn't mount it itself? Nov 04 16:29:44 why does it need initramfs? it should suffice to just mount a few basic things Nov 04 16:30:55 oh wait never mind I'm dumb Nov 04 16:30:55 it needs it, as when we wrote it, we had an initramfs, so it was never debugged without one.. Nov 04 16:32:54 ok, re-enabled the two initrd files i've renamed, it is in "supercar" mode, now Nov 04 16:33:13 dang it.. wrong image.. re-enable flasher.. Nov 04 16:33:36 or cylon mode, whatever you like more :) Nov 04 16:33:41 okay good.. cylon Nov 04 16:34:34 i'm just always surprised, no one really recognizes it as cylon mode.. Nov 04 16:35:29 i watched more TV when i was younger (supercar) than in my (pre)teen age (Galactica). So to me that thing means "supercar". Nov 04 16:35:53 Parduz: we just side-step the issue by not flashing the contents of sd card to eMMC, but rather sd card just has a minimal bootable system, image file(s), and a flasher script that writes the image to eMMC, expands it, and "personalizes" it (random fsuuid, machine id, set hostname, generate ssh keys) Nov 04 16:36:37 (the image being made from a "prototype" system on eMMC) Nov 04 16:37:44 zmatt: i see that as the right way for me also. Problem is that the amount of knowledge i'd need to do the same is still to be obtained. Nov 04 16:38:06 and i'm in a desperate shortage of time. Nov 04 16:39:33 Here the message, and matching function.. https://gist.github.com/RobertCNelson/3cc015244175fa61109ad006fee1a7ab we are looking at /proc/cmdline to figure out which drive we booted on, so we can flash the other.. Nov 04 16:39:59 rcn-ee[m]: and he already said he got the "no /proc/cmdline" message Nov 04 16:40:06 (which should probably be a fatal error, but isn't currently) Nov 04 16:40:25 the only obvious reason would be that /proc isn't mounted Nov 04 16:57:52 well, thanks Nov 04 16:57:56 have to go Nov 04 17:08:32 jkridner: has there ever been communication with Microchip about the BBB's ethernet phy issue? because its reset timing seems to be perfectly compliant to the phy's datasheet, so it would seem to be a phy erratum Nov 04 17:09:25 not that I know of. Nov 04 17:10:51 wonders how much of th smsc group is really left at microchip.. Nov 04 17:12:16 so far it seems the failure probability is directly correlated to the rise time of the reset line... I've just started the test setup with both caps removed so reset rises instantly... we do have a reset extender to ensure adequate reset timing is maintained, but with the caps removed that could also be done with a simple u-boot change (since without the caps, the am335x will be able to drive reset ... Nov 04 17:12:22 ...low at reboot, so all it would need to do is wait 5 ms and reboot on the first boot after power-up) Nov 04 17:13:20 so if that works out, it could be fully fixable with a tiny u-boot patch and the omission of two caps Nov 04 17:14:34 (it would need a bump of the board revision in eeprom to ensure u-boot knows whether the board has the caps or not) Nov 04 18:07:11 Any checklist for securing a BBB connected to internet? e.g. iptables for ssh, and ssh without root login... closing other doors, like the default webserver ?? Nov 04 18:08:57 remove bonescript Nov 04 18:09:05 check to see if cloud9 and node-red are running as root. Nov 04 18:09:43 CoffeeBreakfast: it would be easier to start with an image with none of the special things running: https://elinux.org/Beagleboard:BeagleBoneBlack_Debian#Debian_Stretch_Console_Snapshot Nov 04 18:16:56 I assume it's different from the IoT image at beagleboard.org, right? Nov 04 18:25:32 CoffeeBreakfast: yes, just way less stuff. Nov 04 18:26:18 (it's the same script that generates the beaglboard.org images) Nov 04 18:35:29 thanks! Nov 04 18:45:52 CoffeeBreakfast: if you intend to have ssh exposed to the internet, maybe consider using public-key authentication and disable password-authenticatoin entirely Nov 04 18:58:04 yes, it is a good idea Nov 04 19:04:21 ssh certs also neat when the desire exists to be able to authorize additional keys without having to modify anything on the target device(s) Nov 04 19:12:42 weirdest thing happened over the weekend Nov 04 19:13:08 the BBAI power consumption went from ~800mA down to 220mA Nov 04 19:14:53 was that change accompanied by a a puff of smoke? Nov 04 19:15:13 ;) Nov 04 19:16:21 no, things are still working...that's the weird part Nov 04 19:16:37 as if the kernel requested a suspend and eventually the HW agreed Nov 04 19:17:08 even slamming the A15 with a ./configure for a package isn't pushing current consumption above 250mA Nov 04 21:58:34 zmatt: so two weeks ago I mentioned the spi-test in py-uio worked at 24MHz but not at 1MHz. I'm revisiting that now and I think I see the problem. The MISO line has a high/low of 3.3V/1.5V and the MOSI line has a high/low of 2V/0V. Nov 04 21:59:13 The MISO is what the PRU is outputting, and I'm guessing that there is another pin conflicting with it. Nov 04 21:59:28 This is with the BBAI BTW Nov 04 22:00:27 uhh so check the pinmux state Nov 04 22:00:36 neither of those sound right Nov 04 22:00:43 Here is what my show-pins returns https://pastebin.com/raw/k0SzbUda Nov 04 22:01:06 The pin in question MISO is P8.34 Nov 04 22:01:16 hunter2018[m]: uhh what happened here? this looks like you're missing cape_pins_default Nov 04 22:01:59 though there actually doesn't sem to be any conflict on the miso/mosi pins Nov 04 22:02:42 (but there is on a whole bunch of other pins and this pinmux state is overall a very bad idea) Nov 04 22:03:40 which pru pins are you using Nov 04 22:03:47 wait never mind I see them Nov 04 22:04:04 P8.34 has a drive conflict Nov 04 22:05:07 Hmm... I can't remember how I reverted to that. Here is my am5729-beagleboneai-uio.dts https://pastebin.com/raw/1k5G5QU4 Nov 04 22:06:07 And here is the bbai-spi-test.dtsi file: https://pastebin.com/raw/TJcA3hGJ Nov 04 22:06:33 you didn't comment out all pins you're using Nov 04 22:06:44 P9.11a and P9.13 Nov 04 22:07:24 so the kernel detected a pinmux conflict and prevents the cape_default device from being allowed to set its pinmux (with a complaint in the kernel log obviously) Nov 04 22:08:55 Oh thanks! I forgot what I was doing a week ago. I believe you were helping me get UART working, and I only enabled P9.11a and P9.13 without commenting out the lines. Nov 04 22:09:25 you can't have two pinmux blocks in use that both try to use the same pin Nov 04 22:09:44 BTW, when building the device tree after making changes it seems that I have to run "make clean" for it to do anything. If I just run "make" it says all files are up to date. Nov 04 22:10:03 sounds like a bug in the makefile? Nov 04 22:10:18 of some sort Nov 04 22:10:32 either that or the file dates are weird Nov 04 22:10:37 hunter2018: yeah, if your editing one of the includes, the main *.dtb doesn't get rebuilt.. Nov 04 22:10:48 ah, missing dependency tracking Nov 04 22:11:44 aw, I was wondering if maybe my overlay-utils includes an automatic dependency tracking rule, but it actually doesn't Nov 04 22:11:50 shame on me Nov 04 22:18:15 Ok, this pinmux state looks like now. https://pastebin.com/raw/h2exBWxz Nov 04 22:19:20 Ok, much better now. Both of my SPI data lines have the correct voltages. Nov 04 22:21:51 I do see some pull-up/down conflicts (P9.29a/b, P9.31a/b, P9.42a/b, and the pull-down on P8.31 presumably also conflicts with the pull-up of the spi pin it's connected to) Nov 04 22:22:04 you may want to resolve these for the long-term health of the I/O cells Nov 04 22:23:59 rcn-ee[m] zmatt: https://github.com/jadonk/u-boot/commit/ce02a3e97aa071f46e4a5a956d595cd64c5ee1b5 Nov 04 22:24:24 Ok, now I'm back where I was last week. It still works at 24MHz but not slower rates like 4MHz Nov 04 22:24:34 Let me retry changing the max speed in the device tree. Nov 04 22:26:09 hunter2018[m]: I think last time I suggested some lines of code to produce debug output? Nov 04 22:27:16 Yeah, let me try that now. I set the speed to 23MHz and it only makes 26 bit errors compared to 125 bit errors for 4MHz and zero for 24MHz. Nov 04 22:27:36 23 MHz = 16 MHz .. it can't actually do 23 MHz :P Nov 04 22:28:57 note also that the number of bit errors will presumably vary from run to run since it uses random data Nov 04 22:30:13 when I get home I'll try the test at lower speeds on my bbx15 Nov 04 22:31:47 rcn-ee[m]: did you figure git bundles or not had chance yet? Nov 04 22:32:41 veremitz: no, been getting the Green Gateway sbc ready for Seeed.. Nov 04 22:33:28 ooh new shiny? Nov 04 22:33:47 zmatt: How should the rx and tx buffers be related? Nov 04 22:34:50 hunter2018[m]: pruout[t+1] = pruout[t] XOR pruin[t] Nov 04 22:35:14 (pruout[0] = 0 ) Nov 04 22:35:46 so pruout=rx and pruin=tx Nov 04 22:36:38 rcn-ee[m]: ah just BBB+wifi :D lol Nov 04 22:37:00 veremitz: it's nice fix'ed board.. it's like the beaglebone black wireless, except a 12v rail, extra usb phy, rtc, and grove connectors. Nov 04 22:37:14 hunter2018[m]: I don't suppose you can make a scope pic (at lower speed) ? Nov 04 22:37:47 rcn-ee[m]: ah missed those :D Nov 04 22:38:11 Sure can! The funny thing is that it looks like total and complete garbage at 24MHz (where it passes), probably because I just have probes hanging off the jumpers. Nov 04 22:38:57 veremitz: first board in beagleboard.org's era with a rtc that actually works.. (it's a dallas dsxx on the i2c bus) Nov 04 22:38:59 rcn-ee[m]: some nice additions there I s'pose.. Nov 04 22:39:16 rcn-ee[m]: one of the tried-and-tested :D Nov 04 22:39:43 veremitz: with a battery plug for the rtc.. we've never had a board that could keep time out of the box.. ;) Nov 04 22:39:57 rcn-ee[m]: one of very few! Nov 04 22:40:18 x15, remove resitor and add battery, so that was close Nov 04 22:40:55 is there any hw info available yet? seeed only has a 'coming soon' page.. does it belong in the Beagle family still? Nov 04 22:42:44 ugh I have linux stuff to do .. and I got distracted :P lol Nov 04 22:43:10 It's pretty much a BeagleBone Black Wiresless: - noHDMI + Ethernet Jack - 12V, RTC, 2x Grove Connectors.. Nov 04 22:45:32 ah so that's where the board space came from . no HDMI framer :D Nov 04 22:46:05 zmatt: Here is a passing test at 24MHz https://pastebin.com/raw/fNm6wYRQ, and here is a failed test at 1MHz https://pastebin.com/raw/2EJRcdfg Nov 04 22:46:33 and the small octavo sip Nov 04 22:46:40 *nod* Nov 04 22:46:52 did TI spin that one out? Nov 04 22:47:13 or did octavio get a license/etc Nov 04 22:47:22 and the big smsc usb phy.. (same one used on the xm/panda era) Nov 04 22:47:42 oh the ethernet isn't on usb again .. :/ Nov 04 22:47:55 the cpu has rgmii :( Nov 04 22:48:17 yeap, jason told them that... they put it on the usb.. Nov 04 22:48:25 ah ffs :/ lol Nov 04 22:48:55 so my original revC BBB is still my preferred USB-HDD-NAS then ;) Nov 04 22:49:07 or revB :p Nov 04 22:49:11 even with musb ;) Nov 04 22:54:01 zmatt: Ok, something weird is going on. Here is the signal at 1MHz (where it fails) https://pasteboard.co/IFbWYs5.png Nov 04 22:54:27 rcn-ee[m]: I was almost excited then .. :/ lol Nov 04 22:55:17 hunter2018[m]: yellow = spi->pru, blue = pru->spi ? Nov 04 22:55:33 And here it is at 24MHz where it passes: https://pasteboard.co/IFbXJ5q.png Nov 04 22:55:45 it looks okay apart from the awful ringing Nov 04 22:55:54 CH1 is the hardware SPI MOSI and CH2 is from the PRU MISO Nov 04 22:56:11 The 24MHz doesn't even look remotely right... Nov 04 22:56:23 it does but you'll need to zoom in Nov 04 22:56:46 the long pauses mean the kernel driver is being terribly inefficient at performing the transfer Nov 04 22:58:49 Ok, here it is zoomed in... https://pasteboard.co/IFbZ1mK.png Nov 04 22:59:27 Let me grab a 4 channel scope, I can't tell what's going on without the clock. Nov 04 22:59:47 wait I think my description of the tx/rx relation might be wrong, lemme double-check Nov 04 23:01:33 you know what Nov 04 23:01:38 the test is wrong Nov 04 23:01:45 the data is right at 1 MHz and not at 24 MHz Nov 04 23:02:29 lulz :/ Nov 04 23:03:23 I think Nov 04 23:06:17 hunter2018[m]: https://pastebin.com/raw/M55pyu3B this shows how the tx and rx relate in the two cases (I've replaced 0s by dots for readability) Nov 04 23:07:27 oh yeah this actually makes perfect sense Nov 04 23:08:35 at 24 MHz one cycle is 42 ns, so I think you'll already get more than half a clock cycle of delay simply getting the signals into and out of pruss Nov 04 23:09:23 so effectively this delays the pru output (miso) by one clock cycle Nov 04 23:10:28 also maybe use shorter wires or add some series resistors near the driving side of each line since this is some serious ringing :P Nov 04 23:12:22 it would probably help if I'd update the outputs on rising edge rather than falling edge (counting on the delay to be sufficient to meet the master's hold time requirement for miso) Nov 04 23:14:03 hunter2018[m]: two swapping the "xor" and the "wbs" instructions in the pru firmware :) Nov 04 23:14:07 *try swapping Nov 04 23:16:25 that might result in out[t+2] = out[t+1] xor in[t] for low and high speeds Nov 04 23:16:47 moving the xor to the end of the loop might result in out[t+1] = out[t] xor in[t] for low and high speeds Nov 04 23:17:07 (but it wouldn't be strictly spi-compliant timing anymore) Nov 04 23:19:13 the way I've written the program currently is semantically correct though, it just means 24 MHz is too fast to work without hacks like the aforementioned twekas Nov 04 23:19:25 and I need to fix my test Nov 04 23:28:04 unrelated to the current thread - does the x15/BBAI have a PDM input? (i.e. for a mic) Nov 04 23:29:12 no, just a whole bunch of McASPs Nov 04 23:32:56 so one must burn a PRU to do that Nov 04 23:33:22 or use an i2s mic :P Nov 04 23:33:47 do they come with a easy way to coordinate a pair ? Nov 04 23:35:08 I don't think I have seen any cheap P/N for an integrated I2S mic... do you have a P/N off hand? Nov 04 23:35:25 "The microphone is a single mono element. You can select whether you want it to be on the Left or Right channel by connecting the Select pin to power or ground. If you need stereo, pick up two microphones! You can set them up to be stereo by sharing the Clock, WS and Data lines but having one with Select to ground, and one with Select to high voltage" Nov 04 23:35:49 and of course if you want more than two mics just use a data line per mic (shared clocks) Nov 04 23:36:35 oh nice...just like PDM mics (1 pin selects rising or falling edge of clock for output) Nov 04 23:37:08 jumping back to the BBAI thing - I wonder if the problem is simply SW thinks the A15 is at 400MHz but HW is running the cores at 1.5GHz Nov 04 23:37:23 seems unlikely Nov 04 23:37:41 I do recall playing with the cpufreq stuff and being disappointed that I cannot change the cpu freq to anything besides 400MHz even though the others are listed as options Nov 04 23:38:22 I am in this wierd condition where power draw is <300mA regardless of what I do on the A15 Nov 04 23:38:51 the OPPs are 1 GHz, 1.176 GHz, and 1.5 GHz Nov 04 23:39:30 I'm not convinced configuring a lower clock frequency makes sense if cpuidle is working Nov 04 23:42:13 not saying it makes sense...just trying to figure out what is going on Nov 04 23:42:43 it makes no sense for it to be hovering at 800mA after running your util with --retention forced and hten suddenly seeing <300mA Nov 04 23:43:48 the reason I was playing with the cpufreq stuff is the x15 feels very sluggish relative to the Jetson Nano Nov 04 23:43:51 oh the 400 MHz mode jkridner added also undervolts the cpu? I guess then it would help... it does violate the datasheet however :P Nov 04 23:44:31 it also doesn't make sense running my util with --retention would increase power consumption Nov 04 23:45:03 (and I'm pretty sure it doesn't for me) Nov 04 23:45:06 yes, nothing makes much sense here Nov 04 23:45:14 just to be clear - Nov 04 23:45:36 before your util, it was bouncing around 1000mA-900mA...after ur util it bounces around 800mA Nov 04 23:45:45 ah Nov 05 00:30:09 the mystery is why did it over the weekend drop to this 300mA range Nov 05 00:30:09 I misinterpreted Nov 05 00:30:09 sorry, I was being confusing Nov 05 00:30:09 half of me is doing battle with autoconf Nov 05 00:30:09 did running TIDL a few times somehow appeased EVE/DSP enough to get them to idle or was it my messing with cpufreq that did that Nov 05 00:30:09 btw if you're in doubt about cpu frequency and such, you could check 'omapconf show opp' (unfortunately it's mising EVE3 and EVE4) Nov 05 00:30:09 grabbed it right now when it is low Nov 05 00:30:09 you can check the EVEs with: sudo omapconf dump prcm | grep -P 'M_EVE.*(PWR|CLK)' **** BEGIN LOGGING AT Tue Nov 05 00:30:27 2019 Nov 05 00:31:29 I think I just narrowed the range from the 1GHz operating point as I recall. Nov 05 00:31:53 I didn't notice at first, but have noticed now, that the boot messages say the voltage is invalid. Nov 05 00:32:21 the state it is right now doesn't allow for anything BUT the 400MHz setting Nov 05 00:32:32 datasheet specifies that without AVS only 1 GHz is permitted with VD_MPU min 1.06V typ 1.15V max 1.2V Nov 05 00:34:36 ds2: the governor is likely set to "powersave". Nov 05 00:34:46 the min and max values in the DT for the three OPPs in dra7.dtsi are the range in which the AVS voltage is permitted to be Nov 05 00:34:47 jkridner: changed it to user Nov 05 00:35:04 and, if it gets over something low, like 60C, it locks the frequency. Nov 05 00:35:17 probally that's it Nov 05 00:35:28 that doesn't sound like a good power management strategy Nov 05 00:35:53 jkridner: different thing - does the TIDL model conversion tools exists and if so, where can one find them? Nov 05 00:36:42 er, 55C: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.14.x-ti/src/arm/am5729-beagleboneai.dts#L1121-L1123 Nov 05 00:37:02 ds2: I'll be back in a bit and see if I can find the link to it. I had it at one point. Nov 05 00:37:15 since you're not allowed to lower the voltage below that for OPP_NOM (1 GHz), I'd kinda expect that running at a lower frequency would just increase power consumption for a given workload since it would reduce the time spent in idle Nov 05 00:37:17 thanks. Nov 05 00:38:02 once I sort out the stuff, I can test the temperature stuff ... got a nice peltier cooler sitting around here }:-) Nov 05 00:38:12 of course that only applies when cpuidle actually works :P Nov 05 00:41:04 jkridner: the OPP_NOM AVS voltage for a device can be anywhere in range 0.85V-1.15V, so changing the upper limit to 1.10V as you do in your "opp_slow" may result in the required AVS voltage being forbidden ... I think Nov 05 00:57:18 ds2: hm, from those values I don't immediately see an obvious reason why it would refuse to enter idle... but it's a bit difficult to say because of the refrigerator light problem (querying EVE's registers temporarily causes it to exit (attempted) idle) Nov 05 01:03:40 rah: removed C24 and C30 (so reset rise time is basically instant), reset extender and 1K pull-up are still present (though the pull-up is probably superfluous) ... so far 0 phy failures in 3010 power-cycles Nov 05 01:04:03 ds2: https://git.ti.com/cgit/tidl/tidl-utils/about/ Nov 05 01:04:39 rcn-ee[m]: need to check the license on ^^^ and see if we can include it. Nov 05 01:06:41 jkridner: looks normal license from ti: https://git.ti.com/cgit/tidl/tidl-utils/tree/docs/LICENSE.txt Nov 05 01:08:20 I'm about to shut down for the night. I hope to get back to u-boot debugging tomorrow. Nov 05 01:08:36 let me know if I've got the pinmuxes in as good a state as can be. Nov 05 01:13:43 rcn-ee[m]: btw, at the ELC-E workshop last week, I found the upcoming Mac OS X appears to now replicate the Microsoft Windows 10 update bug where no more drivers are loaded as soon as one is enumerated for which the OS doesn't have a driver. I say that because I was able to load the CDC ECM driver *before* the RNDIS driver and then the driver loaded, whereas it did not load in the other order on this machine. Joy. Windows or Mac again... Nov 05 01:13:44 . not both. Thank you MSFT/AAPL. :-( Nov 05 01:15:25 jkridner: so what's our plan.. do we know anyone at apple to report it as a regression to get the old functionality back? Nov 05 01:16:53 On the bright side, windows 7 goes EOL next month.. So we are down to Windows 8-10, plus all the mac varients.. Nov 05 01:21:05 rcn-ee[m]: there's a bright side?! :p Nov 05 01:22:25 our usb-serial gadget doesn't work on windows7, microsoft added it in window 8.. ;) Nov 05 01:22:52 ugh way-to-go movnig goalposts.. Nov 05 01:23:03 still, keeps you busy, right?! ;) Nov 05 01:23:27 it's more annoying.. Nov 05 01:23:42 i'm hopeing with WSL 2.x it'll just use the linux driver... ;) Nov 05 01:23:54 hahaha good luck! Nov 05 01:25:26 doh, come on! enable usb. https://github.com/microsoft/WSL2-Linux-Kernel/blob/860d9514d04e5ec0c759decde7d4591b15dfcef1/Microsoft/config-wsl Nov 05 01:25:30 so there goes that.. Nov 05 01:25:37 ahaha Nov 05 02:11:23 avoid windows. life is better that way. Nov 05 02:13:48 ^ Nov 05 02:14:55 jkridner: is it suppose to be a binary tool as indicated in the readme? don't see anything other then a eve test tool and a lot of sources Nov 05 02:16:38 rcn-ee[m]: could you make heads/tails of the tidl-utils repo? Nov 05 02:37:54 hmmm **** ENDING LOGGING AT Tue Nov 05 02:59:58 2019