**** BEGIN LOGGING AT Mon Oct 28 02:59:58 2019 Oct 28 05:12:26 b/c of the fires in CA, the Oriely book site online is down. Does this sound right? Oct 28 05:14:30 Is there going to be an upate to "Running Linux? Oct 28 05:15:01 " Oct 28 05:15:48 I am asking b/c the dang IRQ stuff for .C files is giving me the willies. Oct 28 05:16:09 I know that makes no sense! This is b/c the dang book might be too old! Oct 28 05:28:20 I guess I was really asking b/c I know nothing, as you all are aware, about setting up GPIO under .c files w/ specific .h files, macros, and related source. Oct 28 05:28:21 ... Oct 28 05:29:08 Right now, I am trying to type up a small file for GPIO in .c but I want to understand what I am doing and not what I can do while not understanding. Oct 28 05:29:10 Right? Oct 28 05:29:28 I am reviewing the TRM for the older am335x. Oct 28 05:30:05 I am also reading a book on the Cortex-M based microcontrollers. Oct 28 05:30:16 But... Oct 28 05:34:33 I need a set up on how to go about picking and placing the correct data from the TRM into a .c file for GPIO access. Oct 28 05:44:48 I mean... Oct 28 05:46:28 What education is out there outside of schooling and/or online education? Oct 28 05:48:29 I want to figure out how to read the TRM for the am335x and pick/place vital info/data while setting up a small script. Oct 28 05:50:35 Can anyone (will anyone) recommend something? Oct 28 06:00:39 <--- will check back soon! I feel very good about what I typed thus far. Oct 28 06:08:10 @zmatt, thanks for your heads up on my I2c issue a few weeks back. after making that change, i've had had continous operation with no crashes. Oct 28 06:32:35 :thumbsup: :D Oct 28 06:48:21 best part is that i also now udnerstand what the problem was Oct 28 06:49:57 +2 :D Oct 28 09:22:08 if i'd want to remove all the buttons from a LCD4 cape, free the pins used by them, and change the key associated to the remaining one, i should edit the BB-BONE-LCD4-01-00A1.dts file and then rebuild it, right? Oct 28 09:24:06 or, to say it better, copy that .dts to "myowncape.dts", make the changes, build it and load "myowncape.dtbo" in the uEnv.txt file, right? Oct 28 11:35:17 yup Oct 28 11:35:50 be sure to configure it in the correct variable in /boot/uEnv.txt corresponding to the i2c address used by the cape so it overrides the autodetection Oct 28 11:36:54 ok, so i've commented out all entries related to the button pins but the "RIGHT" key one. Oct 28 11:37:02 now how can i compile it? Oct 28 11:37:16 make src/arm/myowncape.dtbo Oct 28 11:37:32 uh.... Oct 28 11:37:35 executed in the root of the repository Oct 28 11:37:37 i tried dtc -O dtb -o BB-BONE-LCD4-PHASE-001.dtbo -b 0 -@ BB-BONE-LCD4-PHASE-001.dts Oct 28 11:37:42 no Oct 28 11:37:51 don't try to manually compile it, use the makefile Oct 28 11:39:09 ok.... the src/arm/ folder is the one in /opt/scripts/tools/bb.org-overlays/ or in /opt/source/bb.org-overlays/ ? i have both Oct 28 11:40:04 the latters contains only dts, not dtbo Oct 28 11:41:06 dunno why there'd be two checkouts of the repository, I'd lean towards the /opt/source one. either way just make sure it's uptodate (git pull) and it shouldn't matter which Oct 28 11:43:14 i think the former was created when i've done "sudo apt install bb-customizations" Oct 28 11:45:37 that sounds unlikely, bb-customizations shouldn't install anything in /opt Oct 28 11:49:06 maybe the kernel update, then? i remember seeing something when updating/upgrading the IOT image.... Oct 28 11:49:50 bb-cape-overlays I guess... although I thought that was just the dtbos, lemme check Oct 28 11:52:08 it is just the dtbos and /usr/bin/config-pin Oct 28 11:53:55 i have the dts, and the hidden .dtbo.* files in /opt/scripts/tools/bb.org-overlays/src/arm/ Oct 28 11:54:22 all of them :) Oct 28 11:54:28 uhh what? Oct 28 11:54:36 hidden .dtbo.* files? wtf? Oct 28 11:55:30 like I said I suggest using the /opt/source one... I know it's supposed to be there, dunno what it's doing in /opt/scripts/tools, it seems like a weird place for it Oct 28 11:55:46 either way make sure it's uptodate using git pull Oct 28 11:55:52 then it won't matter which you use Oct 28 11:56:18 assuming there's a .git directory in the bb.org-overlays directory that is Oct 28 11:56:25 if not, then just don't use that directory at all Oct 28 11:56:50 (if need be just clone it from the github repository yourself) Oct 28 11:57:22 yep.... i've make it there. Oct 28 11:57:35 ? Oct 28 11:57:49 you've made what where? Oct 28 11:58:41 the dtbo file. Now it is in the src/arm/ directory. should i "install" it? the dtbo should be in the firmware directory? Oct 28 11:59:00 yeah just copy your custom dtbo to /lib/firmware/ Oct 28 11:59:05 k Oct 28 11:59:24 it's not strictly required since you have to specify the full path in /boot/uEnv.txt anyway, but it seems like the right thing to do Oct 28 12:02:49 I see now what you probably meant by ".dtbo.*" files, the makefile creates a bunch of intermediate .$name.dtbo.* files as part of the build process Oct 28 12:52:46 yup, that was what i meant Oct 28 12:56:22 it still loads the LCD4 dtbo instead of mine Oct 28 12:56:24 cmdline:[console=ttyO0,115200n8 bone_capemgr.uboot_capemgr_enabled=1 root=/dev/mmcblk1p1 ro rootfstype=ext4 rootwait uboot_detected_capes=BB-BONE-LCD4-01, coherent_pool=1M net.ifnames=0 Oct 28 12:57:05 that just says it *detected* the cape, which seems fine Oct 28 12:57:28 oh.... ok. Oct 28 12:57:50 to easily verify which overlays are used, customize this line in the dts: https://github.com/RobertCNelson/bb.org-overlays/blob/master/src/arm/BB-BONE-LCD4-01-00A1.dts#L75 Oct 28 12:57:56 change its name to that of your custom overlay Oct 28 12:58:44 then at runtime you can inspect /proc/device-tree/chosen/overlays to determine which dtbos were loaded and more specifically which builds thereof (they contain the build date) Oct 28 12:59:47 done .... dunno if is "part-number = "BB-BONE-LCD4-PHASE";" or " BB-BONE-LCD4-PHASE-001 = __TIMESTAMP__;" the relevant line Oct 28 12:59:58 gonna check that folder Oct 28 13:00:36 this is unrelated to the part-number = ...; line Oct 28 13:00:47 (which is ignored by u-boot) Oct 28 13:01:00 ok, it loaded mine Oct 28 13:01:46 should i disable detection and just load my dtbo? does it speed up boot time? Oct 28 13:02:25 no Oct 28 13:02:47 I'm pretty sure cape detection time is completely negligible Oct 28 13:03:59 oh! Where should i copy my boot graph svg so you can take a look? Oct 28 13:04:08 more than one minute to boot Oct 28 13:04:14 just the kernel takes 20s Oct 28 13:09:27 add this kernel parameter (i.e. add it to the list of options in the "cmdline" variable in /boot/uEnv.txt): rng_core.default_quality=100 Oct 28 13:10:02 anyway, bbl Oct 28 13:11:14 that parameter is already there Oct 28 13:45:34 uhh not in what you just showed Oct 28 13:45:46 can you confirm it's present in /proc/cmdline ? Oct 28 13:47:44 oh maybe the line you pasted just got truncated Oct 28 13:49:41 yep, i just taken the part about the cape Oct 28 13:49:57 it was part of the output of version.sh Oct 28 13:51:14 jeez the ethernet of the BBBs are driving me crazy!!! I cannot connect to it anymore! Oct 28 13:52:28 no eth leds, systemctl restart network says "network.service not found" Oct 28 13:53:07 if the eth leds are off then it doesn't detect a link Oct 28 13:53:29 there's nothing to "start", and certainly not "network.service" whatever that might be Oct 28 13:53:57 main reasons for failing to detect a link would be a cable that's not plugged in properly or a broken cable Oct 28 13:54:17 unless you mean link up fails immediately after boot Oct 28 13:55:06 (I interpreted the "I cannot connect to it anymore" as meaning it suddenly dropped link, but maybe that's not what you meant) Oct 28 13:55:10 the cable is there from tuesday.... it is something going wrong at boot. If no green led, or green led lit but "fix", no ethernet available. Oct 28 13:56:42 the ethernet phy on the BBB is known to sometimes have an issue where it fails to initialize properly at power-on, which is fixable only by power-cycling or hard-resetting (with the reset button) .. the latter being preferable since it is guaranteed to resolve it (while power-cycling has a small risk of causing the problem again) Oct 28 13:57:20 it is fortunately quite rare, but nevertheless annoying Oct 28 13:58:05 well, on my 8 BBBs happens quite often! Oct 28 13:58:19 thanks for the info, though Oct 28 13:59:36 afaik the only way to fix it that's relatively simple is using an external reset circuit to hold reset low for longer (25ms or more) after the 3.3v supply has come up Oct 28 13:59:55 (the reset line is available on the P9 connector) Oct 28 14:00:44 this is a precious info Oct 28 14:00:49 many thanks Oct 28 14:01:51 perhaps with a bit of extra pull-up on it to make it rise faster, since some people also reported they managed to fix it by removing the ridiculously massive capacitor on the reset line, suggesting the slow rise time might be a problem as well... my guess would be it was intended to slightly extend the reset time Oct 28 14:02:21 (but too much pull-up might be a problem for the open-drain drivers that need to be able to drive the reset line low) Oct 28 14:03:43 got it. and told to the other guy here (he's the hardware man :) ) Oct 28 14:05:39 on our latest prototype we added a TLV803S and a 100K pull-up, but we haven't yet tested whether this indeed resolves the issue Oct 28 14:09:46 (someone also posted a "software only" solution which however seems to me like an excellent way to damage the hardware in the long term) Oct 28 15:01:50 yes, I did accidentally take down beagleboard.org :-( Oct 28 15:02:15 I initiated a backup because I found out that ARM instances on EC2 were quite a bit cheaper than x86 instances... Oct 28 15:02:26 and, I'm locked out of the hard drives until the backup completes. Oct 28 15:02:43 I've got the ARM server partially running, with a bit of data missing.... Oct 28 15:02:53 but, the DNS records will take a while to update. Oct 28 15:03:32 bbb.io refresh (TTL) was set to 1 day, rather than 1 hour, so it'll take longer to propagate. :-( Oct 28 15:14:02 the site seems to work here Oct 28 15:14:14 somewhat Oct 28 15:23:11 I am getting like 76-78C temps from the BB AI just sitting there. And stress test takes 8 minutes before hitting 85C overload. Board is very hot. Any chance this is a software issue partly? Oct 28 15:23:29 it probably is yes Oct 28 15:23:42 load average is 0.08 Oct 28 15:24:24 at the very least the idle temperature should be lower... dunno about the stress test Oct 28 15:27:02 I found at least one apparent issue with power management... for testing purposes I made a quick and disgusting hacky tool that manually pokes some registers via /dev/mem, https://liktaanjeneus.nl/bbx15/omap5-cpu-prcm.tar.gz ... it lets you select between three cpuidle options: --on (default, no lower state entered during idle), --inactive (allow clock disabling in idle), --retention (allow dynamic ... Oct 28 15:27:08 ...power switching in idle) Oct 28 15:28:28 oh, well, seems that i was able to finally obtain some good results.... Oct 28 15:29:00 .... now, i'd really need some help on boot speed. 1min 21s is really too much :( Oct 28 15:30:12 Parduz: yeah I already hate that our devices take 42 seconds to boot (most of which is due to nodejs) Oct 28 15:30:34 zmatt oh, its compiled. Oct 28 15:31:46 hays49: yeah it has some inconvenient build-time deps so it would be a bit annoying to share as source code Oct 28 15:31:56 hays49: can you share the output of: sudo omapconf show opp Oct 28 15:32:28 hmm, omapconf is only showing two of the four EVEs Oct 28 15:33:00 (via pastebin.com or similar paste service) Oct 28 15:33:17 actually a lot of output from omapconf seems dubious Oct 28 15:34:02 well maybe not a lot, but it definitely makes me doubt its reliability Oct 28 15:34:42 ok I will do this but not right this second Oct 28 15:34:47 thanks! Oct 28 15:34:56 also of interest: sudo omapconf dump prcm | grep EVE Oct 28 15:36:26 https://bpaste.net/show/TMS36 Oct 28 15:37:46 zmatt: ^^ I'll be back a bit later-- Oct 28 15:37:49 okay so the eves are indeed running Oct 28 15:37:55 i'm starting to try to remove the initrd* files in /boot/ Oct 28 15:38:02 as is iva Oct 28 15:38:07 i have two of them Oct 28 15:38:15 it has four, omapconf is just bad Oct 28 15:38:36 some of the images need to be restored and all of the disk images need to be restored. Oct 28 15:38:45 zmatt running, as in loaded and generating a bunch of heat? Oct 28 15:38:54 about 60% through the "backup" now. Oct 28 15:39:28 hays49: that's nothing something I can tell from this, can you share: omapconf dump prcm | grep -P '[PC]M_(EVE|IPU|DSP|PRU)\d*_(\w*CTRL|\w*STST)' Oct 28 15:40:05 https://bpaste.net/show/EMCHW Oct 28 15:40:16 oh pru doesn't match, duh that's not a power domain Oct 28 15:40:24 well pru doesn't use much power anyway afaik Oct 28 15:43:24 core 0 pwrctrl 0x00030107 pwrstat 0x03000037 clkstctrl 3 lostcontext 0x101 standby 0 wugen 0x07core 1 pwrctrl 0x00030107 pwrstat 0x03000037 clkstctrl 3 lostcontext 0x101 standby 0 wugen 0x07 Oct 28 15:44:34 yeah sorry for the unfriendly output of my tool ;) Oct 28 15:45:16 bits 0-1 of pwrctrl is the requested power state (entered when the cpu is idle): 0=off (only possible for core1), 1=retention, 2=inactive, 3=on Oct 28 15:46:01 bits 0-1 of pwrstat is the current power state, bits 24-25 of pwrstat is the lowest power state reached since last time you ran the utility Oct 28 15:46:30 to change the requested power state do e.g. sudo ./omap5-cpu-prcm --retention Oct 28 15:50:47 ok, removed the two initrd files i have in boot.... gained 20 sec. Oct 28 15:51:22 now the kernel boots in less than 2secs. Oct 28 15:51:56 should i check for something going wrong, that maybe i don't see? Oct 28 15:51:57 Parduz: oh you were still using initramfs? based on the kernel parameters it looked like you weren't Oct 28 15:52:17 i really don't know! :D :D Oct 28 15:52:26 i was just following your suggestions Oct 28 15:52:34 to keep initramfs from being regenerated when you update the kernel or certain other packages, replace initramfs-tools by this dummy version: initramfs-tools_1.0_all.deb (install with sudo dpkg -i FILE) Oct 28 15:52:40 whoops that should have been a link Oct 28 15:52:50 https://liktaanjeneus.nl/initramfs-tools_1.0_all.deb Oct 28 15:52:50 np, i have it Oct 28 15:52:54 oh ok Oct 28 15:52:54 from old chats Oct 28 15:52:56 ok Oct 28 16:01:02 hays49: here's the interpretation of the dumped values: https://pastebin.com/raw/9FpdHXGp Oct 28 16:03:06 the DSPs abd IPUs are fully off, the "IPU" domain (which doesn't seem to include either of the IPUs, I'd need to check what's up with that) is set to turn off when possible, but it's explicitly kept enabled for an uart, the EVEs are powered, enabled, and in a weird state Oct 28 16:04:36 hays49: can you check: journalctl -k -b | grep -iP 'eve\d' Oct 28 16:08:28 I'm pretty sure that some sort of firmware is being loaded onto the EVEs. if you can find whatever the kernel is loading onto them (presumably somewhere in /lib/firmware and mentioned in the kernel log) and delete/rename/move those firmware files then I imagine the system may be a bit cooler Oct 28 16:16:47 zmatt: would you like to take a look at the boot graph? Looking at it i think i could speed up the boot a lot, but i just don't know what to remove and where to do it :\ Oct 28 16:16:57 sure if you can share the svg Oct 28 16:17:27 yup .... a cloud service or there's a preferred place like pastebin? Oct 28 16:18:20 i have dropbox handy, if it is good enough Oct 28 16:20:15 I don't really care as long as it results in a link containing the svg Oct 28 16:21:07 https://www.dropbox.com/s/1hrpum6mxmmni60/boot_analysis.svg?dl=0 Oct 28 16:24:15 maybe this is better: https://sendeyo.com/up/d/e6b9f50ae7 Oct 28 16:30:39 Hi Oct 28 16:31:04 trying to flash eMMC from sd card on Beaglebone Green Oct 28 16:31:16 having issues flashing eMMC Oct 28 16:31:54 Any help would be appreciated!! Oct 28 16:32:33 gautham159: "issues" is far too vague for anyone to possibly be able to help you Oct 28 16:35:21 Parduz: part of the problem is that you're booting from SD card, which only has half the bandwidth of eMMC on the BBB. it seems like loading stuff from card is the bottleneck of boot time, which means the solution is loading less stuff from card, e.g. by disabling unnecessary services. I see a bunch that are not relevant Oct 28 16:36:00 Parduz: generic-board-startup.service is a known offender. afaik you can safely disable it as long as you don't need usb networking (or set it up in a different way) Oct 28 16:36:21 Parduz: which beaglebone model do you have? Oct 28 16:36:44 i'm booting from card 'cause so i can make it a flashing card when finished the tuning app. I have BBB revC Oct 28 16:37:32 do you use usb networking? Oct 28 16:38:03 do you use the 3d gpu? Oct 28 16:38:17 you're not, I just remembered you're using x11 Oct 28 16:38:22 unless I confused you with someone else Oct 28 16:38:24 my kiosk app needs the serial port, the i2c port and the localhost socket. Ethernet port for our purposes but not useful for the customer, USB port for sicks to copy data. everything else is not needed Oct 28 16:38:47 yep, X11 and WXWidgets Oct 28 16:39:33 sudo systemctl disable haveged ti-ipc-dra7xx bb-bbai-tether loadcpufreq robotcontrol bb-wl18xx-wlan0 rc_battery_monitor ti-sgx-ti33x-ddk-um generic-board-startup wpa_supplicant hostapd cpufrequtils dnsmasq udhcpd bb-wl18xx-bluetooth Oct 28 16:39:40 let's start with that Oct 28 16:39:48 wow Oct 28 16:39:54 ok, gonna try Oct 28 16:40:14 I also recommend disabling rsyslog Oct 28 16:40:27 ok Oct 28 16:40:44 since it's kinda redundant with systemd-journald, and logging to file probably isn't a great idea anyway for the long-term health of your eMMC Oct 28 16:41:07 also this with that command? Oct 28 16:41:20 yeah sudo systemctl disable rsyslog Oct 28 16:41:32 k Oct 28 16:41:59 if (e.g. during development) you need persistent logs you can enable persistent journal with sudo mkdir /var/log/journal Oct 28 16:42:21 you can disable persistent journal by removing that directory again (and maybe restart systemd-journald... not sure if that's necessary) Oct 28 16:43:05 k Oct 28 16:43:13 the amount of journal logs saved can be configured in /etc/systemd/journald.conf (see "man journald.conf") Oct 28 16:43:44 do you need a webserver running? if not, sudo systemctl disable nginx Oct 28 16:44:16 also probably sudo systemctl disable bonescript-autorun Oct 28 16:44:28 there's a webserver running?!? Oct 28 16:44:30 and bonescript.socket Oct 28 16:44:36 and cloud9.socket Oct 28 16:44:41 ah, for that stuff Oct 28 16:44:42 and node-red.socket Oct 28 16:44:49 completly forgot about that :D :D Oct 28 16:48:12 using systemd-networkd+systemd-resolved instead of ifupdow+connman might also save time, but I'm not sure. it's also a bit trickier since if you mess up the config then after transitioning it won't have networking hence you'd have trouble logging in to fix the problem ;) Oct 28 16:49:22 do you have a (physical) keyboard attached? if not, disable keyboard-setup Oct 28 16:49:30 ok, lets keep it only if needed Oct 28 16:49:39 a usb keyboard, yes Oct 28 16:49:44 ok, then probably keep it Oct 28 16:52:21 after this let's see a new systemd-analyze plot :) Oct 28 16:59:20 https://sendeyo.com/up/d/e9040886b4 Oct 28 16:59:26 now: Oct 28 16:59:37 my app starts much sooner Oct 28 16:59:45 but the boot takes longer after that Oct 28 16:59:51 wtf is going on Oct 28 17:00:42 "Bootup is not yet finished. Please try again later." is the answer when i SSH in and tried "systemd-analyze plot > boot_analysis3.svg" Oct 28 17:00:46 it looks like something is waiting for something but I can't really well what Oct 28 17:00:52 why is wpa_supplicant running though Oct 28 17:01:23 pretty sure I included that in the list of services to stop... hmm did it get activated by something also... Oct 28 17:02:24 I also still spot node-red.socket Oct 28 17:02:29 oh I think I see the problem Oct 28 17:03:45 check /etc/inittab .. I suspect it has two lines (ignoring comments), one for ttyS0 and one for something else (ttyGS0 or something like that?) ... comment out the latter Oct 28 17:04:52 cant find that file/folder Oct 28 17:05:07 ehh what Oct 28 17:06:15 etc/init/ and etc/init.d/ Oct 28 17:06:22 that's all what i have Oct 28 17:06:39 what results do you get from: grep -s ttyS0 /etc/* Oct 28 17:07:11 - /etc/securetty:ttyS0 Oct 28 17:07:20 oh wait it's just a systemd unit, silly me Oct 28 17:07:34 sudo systemctl disable serial-getty@ttyGS0 Oct 28 17:07:56 ok, done Oct 28 17:08:05 (what was that, anyway?) Oct 28 17:09:20 the usb device interface presents itself as a composite device: 2x usb networking (one rndis, one cdc-ecm), 1x mass storage (a small read-only image with some getting-started stuff), and 1x serial port Oct 28 17:09:30 that service is for spawning a login prompt on that serial port Oct 28 17:09:40 but the usb device is no longer being set up Oct 28 17:09:52 hence it waited for timeout Oct 28 17:10:05 ok Oct 28 17:10:09 so, reboot? Oct 28 17:10:42 Anyone having trouble loading beagleboard.org/ai? Oct 28 17:10:57 yeah jkridner messed up the site, he's working on fixing it Oct 28 17:11:14 Cool. Oct 28 17:12:08 I'm guessing I need that to find board level stuff like where (or if) the com port might be, etc. Oct 28 17:12:59 you should be able to ssh to it via ethernet or usb networking, same as a BBB... maybe it also sets up a wifi access point, dunno Oct 28 17:13:46 I'm in on SSH, but that doesn't tell me physically where things are. I don't see a connector where the Black has one, for example. Oct 28 17:13:56 for what? Oct 28 17:14:00 Com. Oct 28 17:14:04 Uart. Oct 28 17:14:59 I'd also like to discover how to monitor CPU temp. This thing is pretty hot and it's just idling on my desk. Oct 28 17:15:29 like the black it has a header (albeit a different one) for the serial console uart (via an isolation buffer) and a bunch of uarts on the expansion headers Oct 28 17:15:31 I'm guessing all that stuff will be there once the site is working again. Oct 28 17:15:43 dunno how much useful info there is on the site yet tbh Oct 28 17:15:54 thermals is a known issue, and I suspect I found something Oct 28 17:16:05 Ok. I'm guessing the little white guy next to USB C is the serial port? Oct 28 17:16:19 Ooo. Found something good I hope. Oct 28 17:16:20 can you share (e.g. via pastebin) the output of: journalctl -k -b | grep -iP 'eve\d' Oct 28 17:16:22 https://sendeyo.com/up/d/c548cd45a7 Oct 28 17:16:31 Let me work on that. Oct 28 17:16:42 wpa_supplicant is still there :) anyway, much better Oct 28 17:17:17 Parduz: maybe connman is pulling it in as dependency or something dumb like that Oct 28 17:17:50 mh .... should i set a static IP, do you think it will help? Oct 28 17:18:11 https://pastebin.com/ZGnVJgEv Oct 28 17:18:14 no, why would it? Oct 28 17:18:36 Maybe not. Says spam detection. Oct 28 17:18:53 ok. Oct 28 17:19:19 Ragnorok: ok so firmware is being loaded onto the EVEs and crashing, probably leaving them in a power-consuming state Oct 28 17:19:44 Ragnorok: I had hoped the kernel logs included some indication of which firmware it was loading onto the eves.... what's in /lib/firmware ? Oct 28 17:19:50 I've been utterly unable to determine anything about the EVE cores. Is that a secret or am I simply unable to find it? Oct 28 17:20:46 for some reason they're not really documented in the am572x TRM, but they are in some other TRMs, e.g. http://www.ti.com/lit/ug/sprui29f/sprui29f.pdf Oct 28 17:21:29 https://pastebin.com/awL0tDLs Oct 28 17:21:35 Thanks! Oct 28 17:23:02 nothing obvious Oct 28 17:23:33 Frankly I won't be using the EVE cores. If I could completely disable them I'd be okay with it. Oct 28 17:23:41 I do zonder what those large firmware files for the dsp and ipu are Oct 28 17:23:42 I'm simply curious what they are. lol Oct 28 17:23:43 *wonder Oct 28 17:23:51 they're basically bigass linear algebra machines :) Oct 28 17:24:13 I powered this thing about ten minutes before I got on here. I know about next to nothing at this juncture. Oct 28 17:25:36 Neat. Oct 28 17:26:02 I'd like to learn in case there is something we can do that's not really vision related. I mean I've got four of the darned things. lol Oct 28 17:26:13 jkridner[m], rcn-ee[m]: the default image for the BBAI is somehow causing the EVEs to run code that crashes with a bus error, and it appears to cause them to get stuck in a state where they can't enter idle, which probably isn't helping with the thermals Oct 28 17:26:39 zmatt: about wpa_supplicant and DHCP: 'cause i was reading this https://raspberrypi.stackexchange.com/questions/85599/how-to-start-stop-wpa-supplicant-on-default-raspbian and being not an expert i wonder if not needeing dhcp anymore could change in the wpa_supplicant not being loaded Oct 28 17:26:49 Ragnorok: yeah I don't think their utility is limited to video Oct 28 17:26:56 Wow. It's even hotter now. Is there a quick something I can cat that shows CPU temp? Oct 28 17:27:07 I'd be stunned if it were. (wink) Oct 28 17:28:07 Ragnorok: I use this: https://pastebin.com/j077cd2Z Oct 28 17:28:26 Thanks! Oct 28 17:28:39 Parduz: that's not how it works Oct 28 17:28:54 Parduz: it doesn't seem to contribute much to boot time anyway Oct 28 17:29:19 my guess is that connman explicitly pulls it in as dependency Oct 28 17:29:48 but I don't use connman and don't know a great deal about it Oct 28 17:30:02 ok ... i was trying to be useful :D Oct 28 17:30:47 my solution would simply be to setup systemd-networkd and systemd-resolved and remove connman and ifupdown Oct 28 17:31:56 i'll look at that. Oct 28 17:32:17 there's a way to "log" my app starting, in that chart? Oct 28 17:32:49 so i have some "reference" about when it happens? Oct 28 17:33:43 probably not as long as it's an X11 application but not sure Oct 28 17:34:10 k, ill search about it Oct 28 17:34:42 (our qt5 application directly on the framebuffer does run as a systemd service) Oct 28 17:35:30 neat Oct 28 17:36:05 Ragnorok: it might be worth moving /lib/firmware/dra7-* out of the way (and then reboot) to see whether that makes any difference Oct 28 17:36:18 Roit toe. Oct 28 17:37:10 Ragnorok: maybe disable ti-ipc-dra7xx.service while at it, since if the auxiliary cores are disabled there's also nothing to IPC between them :P Oct 28 17:37:34 and since I don't know what it does, I don't know whether it gets grumpy if the aux cores can't load their firmware Oct 28 17:37:37 lol Got it. I'll report back shortly. Oct 28 17:50:41 Ragnorok: I've also made a utility that rudely fiddles with some power management hardware registers of the cortex-a15 subsystem: https://liktaanjeneus.nl/bbx15/omap5-cpu-prcm.tar.gz and running it with the --retention option lowered the idle temperature of my bbx15 by 10 degC. beware that I have no idea why the relevant kernel code doesn't configure it like this or whether it might have a good ... Oct 28 17:50:47 ...reason to. it may adversely affect performance, stability, device lifetime, or the weather. I will not accept responsibility for any explosions or tornadoes caused as a result of using this utility Oct 28 17:53:06 lol Roit toe. Tornados not covered. I moved the fw and disabled the service. Temp seems to be going down but it's not stabilized yet. Oct 28 17:53:36 rebooted? Oct 28 17:53:56 shutdown -r now, yeah. Oct 28 17:54:13 you know there's an equivalent "reboot" command ;) Oct 28 17:54:28 Huh. Oct 28 17:54:54 yeah I know, newfangled stuff kids have nowadays Oct 28 17:56:09 Serious. How are they going to remember anything if it's all so easy? lol Oct 28 17:56:20 Ragnorok: could you share the output of: sudo omapconf dump prcm | grep EVE Oct 28 17:56:42 I'm curious if these steps magically also prevent the EVEs from powering up Oct 28 17:56:54 Ooo. Me three. Hang one. Oct 28 17:57:53 https://pastebin.com/HTru4sKn Oct 28 17:58:07 yep, EVEs are off Oct 28 17:58:31 Sweet. PWRSTS? Oct 28 18:00:46 PWRSTST yeah.. specifically bits 0-1 being zero indicates the power domain is off Oct 28 18:01:03 Thanks. As expected temp's still dropping. Oct 28 18:02:52 I'll see if your thing above has more info on this. There are probably other bits I could disable that would help with dissipation. Thanks for the link! Oct 28 18:03:31 it does sound like preventing the aux cores from starting up had a big impact? Oct 28 18:04:12 brb Oct 28 18:04:17 I think so. It was hovering around 73C, now it's around 65C. It may be stabilized. Oct 28 18:05:05 still seems warmish but nowhere near what it was Oct 28 18:05:29 My thoughts exactly. Oct 28 18:05:34 thanks a lot, zmatt. Time to go home for me Oct 28 18:13:02 wow this thing is acting funny. ssh is kinda unreliable and getting lagginess Oct 28 18:13:13 hays49: wifi or wired? Oct 28 18:13:20 wired Oct 28 18:13:24 odd Oct 28 18:13:37 i think im going to let it sit for a bit Oct 28 18:13:45 temps were around 76C Oct 28 18:14:08 but the whole board gets very hot even the plastic Oct 28 18:15:02 hays49: moving /lib/firmware/dra7* out of the way (and disabling ti-ipc-dra7xx.service just in case) and then rebooting apparently helps Oct 28 18:15:21 Dang. Type too slow. lol Oct 28 18:15:29 im working on getting you the journalctl command Oct 28 18:15:33 as reported by Ragnorok :) Oct 28 18:15:38 Mine went from 73C at idle to 65C. Oct 28 18:15:52 hays49: I got it from Ragnorok already, it wasn't as helpful as I hoped Oct 28 18:16:07 Oct 28 18:12:24 bb-ai-a5fe0afe43 kernel: 44000000.ocp:L3 Custom Error: MASTER EVE2_P1 TARGET L4_PER3_P3 (Idle): Data Access in Supervisor mode during Functional access Oct 28 18:16:10 but it does show the EVEs are somehow started and for some reason crash with a bus error Oct 28 18:16:13 yeah that Oct 28 18:16:52 it seems the EVEs are being started indirectly by either the DSP firmware or the IPU firmware, either of which sounds deeply inappropriate Oct 28 18:17:38 Do you know if the IoT images do that? Oct 28 18:17:46 rebooting now Oct 28 18:17:54 moving those firmwares out of the way ensures the DSPs, IPUs, and EVEs remain disabled at boot Oct 28 18:17:57 Ragnorok: I'd assume so Oct 28 18:18:11 Yeah. Just thought I'd ask. I'll find out. Oct 28 18:30:54 mine might be better.. so far up to 71C Oct 28 18:31:25 up to? down to? Oct 28 18:32:29 Mine took 5-10 mins to settle down. Oct 28 18:44:16 78C idle to 70C idle Oct 28 18:44:16 so improvement Oct 28 18:44:34 still seems pretty warm Oct 28 18:45:07 oh yeah its toasty :) Oct 28 18:50:31 i wonder if there are any thermal issues with Rev A vs Rev A1 Oct 28 18:51:01 erm A1 vs A2 Oct 28 18:51:25 I didn't even know there were revisions, was A1 prerelease I guess? Oct 28 18:53:22 I'm not aware of getting pre-release but this says A1. Oct 28 18:54:46 hays49: where are you seeing a revision "A2" mentioned? Oct 28 18:55:50 stress test im seeing about 78C Oct 28 18:57:29 i don't know the site seems to be down? i think it was Rev A vs A1, or A vs A Rev1 or something like this Oct 28 18:57:59 the site is having problems at the moment yeah Oct 28 18:58:15 Still. (wink) Oct 28 18:58:21 though I don't recall having seen anything about bbai revisions on the site Oct 28 18:58:30 might have been in the github Oct 28 18:58:32 it's buried in teh SRM: https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#rev-a2 Oct 28 18:58:57 hays49: it's just a list of "fixes" today, nothing's been spun up yet.. Oct 28 18:59:05 Hmm. IoT doesn't seem to be available for AI. Oct 28 18:59:35 https://github.com/beagleboard/beaglebone-ai/wiki/System-Reference-Manual#board-changes Oct 28 18:59:45 yep rcn-ee beat me to it Oct 28 18:59:51 rcn-ee[m]: did you catch my message earlier? (about 35 minutes ago) Oct 28 19:00:07 Ragnorok: you can grab it from here: https://rcn-ee.net/rootfs/bb.org/testing/2019-08-03/stretch-iot/ Oct 28 19:00:18 Donkies! Oct 28 19:00:36 So I think I have Rev A1 which doesn't have the pulldown resistor Oct 28 19:00:58 as far as I understand the shipped units do have the pulldown Oct 28 19:01:01 I'm a bit concerned we paid for an AI and got a second round prototype. I would have expected an A1a at least. Oct 28 19:01:13 zmatt: was that about the firmware? i have ti-sdk-06.01.00.08 built, just need to update stretch, hopefully the new opencl-firmware. Oct 28 19:01:27 Ragnorok: do you see a small resistor between RX and GND on the back side of the 3 pin serial connector? Oct 28 19:01:41 rcn-ee[m]: no idea I'm just talking about the latest image as shipped Oct 28 19:02:19 That could be a resistor, sure. Oct 28 19:02:24 rcn-ee[m]: and the big traceback it's dumping in the kernel log :) (not that that's very useful given that it's reporting a bus error caused by an auxiliary code, but that aside) Oct 28 19:02:31 *core Oct 28 19:02:36 yeah that has an old opencl-firmware.. while it works, it crashes on startup.. Oct 28 19:02:48 and causes a lot of heating Oct 28 19:02:51 Ragnorok: that's teh A1A. ;) Oct 28 19:03:01 About 9C worth in my experience. Oct 28 19:03:05 no resistor is A1.. Oct 28 19:03:11 Roit toe. Thanks! Oct 28 19:03:40 Ragnorok and the BBAI? Hmmmmm :D Oct 28 19:04:36 Ragnorok: it was a change the CM made as their version of u-boot halts with any noise, the offfical images need a "space bar" key to break into u-boot.. So they just hacked it as is and shipped it... little bit of suprise.. Oct 28 19:04:45 doesn't ragnorok mean something like end of the world for norse mythology? Oct 28 19:04:58 rcn-ee[m]: wow that sounds like amazing practice Oct 28 19:05:12 rcn-ee[m]: lol Oct 28 19:05:28 I mean, it's good that the pulldown is there, but it's not great that this happened without proper versioning Oct 28 19:05:53 ds2: Except the end of the world is cyclical, but yeah. I recommend further research. (wink) Oct 28 19:06:07 if someone would write up a ECO for the resistor... Oct 28 19:06:08 It's the same issue, we have the BBB... and why u-boot has teh "space bar" key by default, but no cm ever randomly 'fixed' it for us.. Oct 28 19:06:50 rcn-ee[m]: there is a proper resistor on the BBB and the CM's for the BBB are sane folks not these irrational fruit makers ;) Oct 28 19:07:22 Ragnorok: have you tried my utility to see how much further impact it has? (I promise the risk of tornados is really quite small) Oct 28 19:07:53 I ran it for about an hour or so. Seemed to stabilize around 63-64C. Oct 28 19:08:11 Been looking at disabling other bits to see if I can bring it down more. Oct 28 19:08:16 zmatt: do you know off hand if the EVE/IP/DSP/etc can be put into a forced idle/sleep state with a similar type of sledge hammer utility? Oct 28 19:08:28 I'm not sure I need the IPU, DSP, or GPU, for instance Oct 28 19:08:40 DSP might be used by TIDL Oct 28 19:09:03 ds2: moving /lib/firmware/dra7* out of the way (and disabling ti-ipc-dra7xx.service just in case) and then rebooting will leave all IPUs, DSPs, and EVEs powered off Oct 28 19:09:30 Oh. So that's already doing IPU & DSP. Well then there now. Oct 28 19:09:39 it is.. DSP works with the EVE for TIDL.. Oct 28 19:09:40 it'll also break TIDL no doubt Oct 28 19:09:47 zmatt: not an option Oct 28 19:10:12 rcn-ee[m]: but is it NEEDED for TIDL? Oct 28 19:10:27 rcn-ee[m]: the API seems to let you load jobs on either or both Oct 28 19:10:36 Guess I won't get less heat then. Can't see the GPU is doing that much. I'm on SSH. Xorg gets little in the way of CPU time. Oct 28 19:10:41 the big question is do they really need to be kept powered up even when not in active use? Oct 28 19:11:05 Ragnorok: oh disabling the gpu might be useful too yeah, dunno if power management is working for it Oct 28 19:11:16 i should re-state that... EVE and DSP can work with TIDL.. Oct 28 19:11:18 I'll have a better answer to that once I have the IoT image in and do som poking around. Oct 28 19:11:21 you can configure how much of either is used with TIDL.. Oct 28 19:11:28 including none.. Oct 28 19:11:48 rcn-ee[m]: but right now they all seem be powered up and actively clocked regardles of whether they're in use Oct 28 19:12:02 actually no Oct 28 19:12:05 only the EVEs are Oct 28 19:12:21 their module state is "transitioning" Oct 28 19:12:30 i.e. they're failing to enter idle Oct 28 19:12:41 hence clocks remain active Oct 28 19:13:12 but maybe the update fixes that, dunno Oct 28 19:13:23 couldn't you cut off the clock from the CM side? Oct 28 19:13:31 both clocks Oct 28 19:13:37 i and f Oct 28 19:13:39 no Oct 28 19:14:10 what about holding them in reset via the PRCM? Oct 28 19:14:24 prcm can request the module to enter idle, it still has to wait for acknowledge before it can gate clocks Oct 28 19:14:31 holding them in reset is pretty much guaranteed to *prevent* idle Oct 28 19:14:59 thought that also cuts power ? Oct 28 19:15:06 absolutely no Oct 28 19:15:06 t Oct 28 19:15:22 power can only be cut once all clock domains are in idle Oct 28 19:15:32 blah Oct 28 19:16:02 otherwise you'd get protocol errors and would probably need a system-wide power-on reset to get things working again Oct 28 19:16:09 and I am guessing these block all have that complex interlock mechanism like the DSP? Oct 28 19:16:22 not the simple controls like on the UART block Oct 28 19:16:39 well even the uart needs to acknoledge idle, but it will do so readily Oct 28 19:17:28 while auxiliary cores usually have to execute something equivalent to a WFI instruction (after configuring things right) to allow the subsystem to enter idle Oct 28 19:18:28 last time I looked at this was either the O2 or O# Oct 28 19:18:29 O3 Oct 28 19:18:56 omap2/3 power management was quite different from omap4/5 I think Oct 28 19:18:56 UART, SPI, etc have a few simple registers to mess with... the DSP is a PITA Oct 28 19:19:17 rcn-ee[m]: You sent me to 8/3. Is that better than 10/29 or should I use the latest? Oct 28 19:19:27 10/21, sorry. Oct 28 19:19:34 yeah initiators need extra care to ensure there are no outstanding bus transfers Oct 28 19:19:49 to prevent protocol errors in the interconnect Oct 28 19:20:15 Ragnorok: that just matches the beagleboard.org datestamp.. either is fine.. Oct 28 19:20:25 Roit toe. Thanks! Oct 28 19:26:34 Do we need "belenda Etcher"? A normal image writer won't work to make a flasher SD? Oct 28 19:27:23 etcher is a normal image writer, that handles on the fly decompression of the .xz file and after flashing will verify the card contents since sd cards are not very reliable, and it has a user-friendly interface Oct 28 19:27:46 so it's just a reliable way for joe random to flash an sd card Oct 28 19:27:55 Cool. I were hopin'. Thanks! Oct 28 19:29:18 Still hovering around 64C at load .08. Oct 28 19:31:21 Hurm. TI doesn't have much on development with the AM5729, at least not on that devices main pages. Oct 28 19:33:08 tidl has separate documentation at least Oct 28 19:34:12 though I did notice a lack of attention to the am5729, even to the point of saying the am5749 is the highest performance variant with its two EVEs... well yeah it is in your list because you omitted the AM5729 with its four EVEs from that list :P Oct 28 19:34:18 I'm not sure what's up with that Oct 28 19:34:32 maybe docs just haven't updated yet Oct 28 19:34:39 I was looking for any datasheet or pinmaps for the PRU unit on the beaglebone blue, does anyone know where I could find it? (new to working with this board) Oct 28 19:34:42 With the Black I downloaded CCS, installed some custom bits for the PRU, and went to town. It didn't take much in the end. I'm hoping to keep that model. Oct 28 19:35:34 ew, ccs Oct 28 19:35:43 Ah. There it is. I have to load the SDK page first. Oct 28 19:36:06 (shrug) I don't mind it. Beat the tar out of visual studio, which is the other thing I use. Oct 28 19:36:26 falcon92: my pins spreadsheet includes a tab for the bbblue => https://goo.gl/Jkcg0w Oct 28 19:37:06 falcon92: there's a filter view (menu Data -> Filter views) "by connection" that's more convenient for looking up pins Oct 28 19:37:11 I prolly should update my dev system from debian 8 as well. lol Oct 28 19:37:32 we've switched to debian buster a while back Oct 28 19:38:00 and I just use vim to write pru assembly and assemble it with pasm Oct 28 19:38:41 I remember. I went the C route. Works fine for me; they're mostly idling anyway. Oct 28 19:38:42 (and load it onto pruss with py-uio for development or a small bit of custom code for production) Oct 28 19:39:07 mine are mostly idling too, but I care about timing Oct 28 19:39:30 zmatt Thank you, I think that helps Oct 28 19:40:08 My timing is interrupt driven - long as it's done before the next interrupt it's a non-issue. Oct 28 19:40:45 well part of why I'm using pruss is to accurately timestamp stuff Oct 28 19:40:58 I expect to use the exact same firmware on the AI when I get that far, unless I have to change registers for the McASP. Unless the AI doesn't have McASP. Then I'm boned. lol Oct 28 19:41:52 the am5729 has 8 McASP instances, though I'm not sure how many of them are usable via the expansion headers of the BBAI Oct 28 19:42:12 That sounds familiar. I wasn't really worried about their lack. (wink) Oct 28 19:42:31 I do expect control registers to move around though. Oct 28 19:42:45 vs a Black that is. Oct 28 19:42:49 depends on what you mean by that, McASP's registers are still the same Oct 28 19:43:20 Mapping memory location. It may be the same. I barely have my toes wet so far. Oct 28 19:44:11 I mean the number of instances is different so obviously there will be differences in where they are located in the global memory map Oct 28 20:33:16 Ragnorok: since I was curious myself, I've made a side by side comparison of McASP pins available on BBB vs BBAI: https://goo.gl/jiazTL ("BBB vs BBAI McASP" sheet) .. note: 0-based mcasp numbering Oct 28 20:34:46 zmatt: Cool! Oct 28 20:36:06 brb Oct 29 02:51:47 hmmm BRB was 6 hours ago. well ... not like the earth opened up and swallowed people. Oct 29 02:52:16 lol Oct 29 02:52:24 lol Oct 29 02:52:31 you say that .... Oct 29 02:52:54 I just got distracted and didn't think of saying "back" Oct 29 03:02:46 It just seemed pretty funny that's all. I suppose I have to look at the BBAI, I guess it's called the AI because they had to give it a name and marketing somehow got involved. Never leave out articles for marketing people to read, they get strange ideas like making a cell phone system etc. **** ENDING LOGGING AT Tue Oct 29 03:02:49 2019