**** BEGIN LOGGING AT Sat Feb 09 02:59:57 2019 Feb 09 03:04:26 Something is not right in Indiana right now. My BBBW has not accepted most of my normal commands w/ upating things and upgrading kernels. I will reply once I am out of ideas. Feb 09 03:12:57 set_: you keep saying such bizarre things Feb 09 03:13:36 I understand. I cannot figure out why this BBBW is booting w/out my uEnv.txt file in working order. I cannot use config-pin either. Feb 09 03:13:53 I am reflashing now. Feb 09 03:15:18 https://pastebin.com/tZTFQssU Feb 09 03:15:26 there's the default /boot/uEnv.txt in case you need it Feb 09 03:15:57 and as usual, if you're booting from sd card rather than eMMC you should consider wiping eMMC Feb 09 03:16:13 Okay. Thank you. If I need it, I will use it. Feb 09 03:16:23 Right. Feb 09 03:16:29 I will wipe that eMMC out. Feb 09 03:16:34 Well... Feb 09 03:16:41 (assuming there's nothing important on it) Feb 09 03:16:57 What I did was add a current image from elinux. Feb 09 03:17:12 what do you mean by that? Feb 09 03:17:24 The BBB.io/latest-images site does not have a flasher image. Feb 09 03:17:30 Oh. I will get the site. Feb 09 03:18:04 https://elinux.org/Beagleboard:BeagleBoneBlack_Debian Feb 09 03:18:09 it doesn't have flasher images, it does have instructions on how to turn any image into a flasher image (by uncommenting one line) Feb 09 03:18:17 Right. Feb 09 03:18:24 which image did you get? Feb 09 03:18:29 I just did not want to make it a flasher and then revert back. Feb 09 03:18:32 The iot Feb 09 03:18:43 full file name please Feb 09 03:18:44 4.14.x iot Feb 09 03:18:58 Okay. Please hold. Feb 09 03:19:24 xzcat bone-debian-9.7-iot-armhf-2019-01-27-4gb.img.xz | sudo dd of=/dev/sdX Feb 09 03:19:30 ok Feb 09 03:19:35 that's not a flasher Feb 09 03:19:37 Right. Feb 09 03:19:45 I already got the flasher done for the eMMC. Feb 09 03:19:53 ? Feb 09 03:20:04 I flashed the eMMC b/c I got a new board. Feb 09 03:20:28 I wanted to have an updated -v of u-boot and not hold the S2 button. Feb 09 03:20:33 you just said you got a flasher from the wiki page, so I ask which image you used exactly, and then you gave a name of an image that's not a flasher Feb 09 03:20:47 Oh. Sorry. Please hold. Feb 09 03:21:20 xzcat BBB-blank-debian-9.7-iot-armhf-2019-01-27-4gb.img.xz | sudo dd of=/dev/sdX Feb 09 03:21:24 and the fact that you also got a non-flasher image means you're also booting from sd card? so why did you reflash eMMC if you're going to boot from sd card anyway? Feb 09 03:21:42 (instead of just erasing eMMC) Feb 09 03:21:55 If I need to take the sd card out for some reason and use the bbbw w/out sd card, I can. Feb 09 03:22:08 so why are you booting from sd card? Feb 09 03:22:14 space Feb 09 03:22:33 o.O ok Feb 09 03:22:38 Zoinks! Feb 09 03:22:43 I guess the iot image is already really bloated to begin with Feb 09 03:23:55 I thought someone had previously used this machine b/c of how it was packaged. Feb 09 03:24:21 Like a warehouse worker or distributor person. I guess they come flashed this way. Feb 09 03:24:45 I'm not talking about whatever was flashed onto it originally (which is the even more bloated lxqt image) Feb 09 03:25:02 Oh. Feb 09 03:25:09 iot already has a bunch of stuff. right. Feb 09 03:25:35 It is already 3.6 GB. Feb 09 03:25:51 It starts as 500MB. Feb 09 03:29:01 I think they put the rt kernel on it. Feb 09 03:29:38 Oh well to that idea. Everything is back to normal. Feb 09 04:01:23 you can probably already free up quite a bit of space with: Feb 09 04:01:25 apt-get purge vpdma-dra7xx-installer ipumm-dra7xx-installer firmware-iwlwifi ti-opencl firmware-am57xx-opencl-monitor && apt-get --purge autoremove Feb 09 04:01:51 this removes a bunch of packages that are not useful on a beaglebone Feb 09 04:18:07 Okay. Feb 09 05:20:37 mawk: lol... https://godbolt.org/z/5FVMaw Feb 09 17:14:32 ok time to get uio-pruss working again on 4.19... ugh, I'm very tempted to first do a cleanup commit on that thing before adding the pruss-v2 stuff Feb 09 18:24:17 zmatt: it seems better to clean something up while you have presence of mind to do so before updating. Just my experience in any case. I could be completely wrong. I prefer to clean things up before modifying the heck out of them. Feb 09 18:59:04 yeah Feb 09 19:02:47 ohh, 4.19-ti isn't just missing uio-pruss, it doesn't have remoteproc-pruss either... and it's even missing the hwmod data for am57xx Feb 09 19:02:54 *remoteproc-pru Feb 09 19:29:16 I mentionned the pru error I have on 5.0 zmatt ? Feb 09 19:29:20 something about clock Feb 09 19:29:29 maybe that's something you want to look at, when 5.0 goes stable and all Feb 09 19:30:35 https://paste.serveur.io/raw/LgHc6SEm.txt Feb 09 20:00:33 mawk: on what kernel is this? Feb 09 20:02:12 5.0-rc2 Feb 09 20:02:19 but there are new rc that are out, let me upgrade Feb 09 20:02:20 mainline? Feb 09 20:02:23 yes Feb 09 20:02:31 5.0.0-rc2-bone-nopreempt0 Feb 09 20:02:36 built with rcn scripts Feb 09 20:02:37 ok so not mainline Feb 09 20:02:42 yeah sorry Feb 09 20:03:26 any changes you did to enable pruss or is this what you get with the standard DT ? Feb 09 20:04:21 it's the standard device tree (am335x-boneblack-uboot-univ.dtb) Feb 09 20:04:24 ah !! my bad Feb 09 20:04:35 it's the standard device tree plus the standard overylay for pru Feb 09 20:04:40 but the standard overlay for an old kernel Feb 09 20:04:45 :) Feb 09 20:04:49 because I didn't edit uEnv.txt in the correct way Feb 09 20:04:49 lol Feb 09 20:04:52 let me try with the good way Feb 09 20:04:54 maybe it ends up with a duplicate definition of pruss? Feb 09 20:05:09 or both the old hwmods and the new sysctrl mechanisms enabled Feb 09 20:05:15 it's just version mismatch I think Feb 09 20:05:39 I have the regular configuration that enabled the pru before, just the old overlay for the new kernel Feb 09 20:05:52 yes but I'm talking about why that might be a problem Feb 09 20:06:06 ah Feb 09 20:06:08 yeah Feb 09 20:06:13 generally overlays are not dependent on kernel version Feb 09 20:06:27 this one has the version in its name Feb 09 20:06:31 and there's an overlay by version Feb 09 20:06:38 I know Feb 09 20:06:40 ah Feb 09 20:06:46 but I've never examined the differences Feb 09 20:07:03 I don't have the new dtbo for my kernel Feb 09 20:07:25 does it need an overlay? Feb 09 20:07:28 ok it's in bb-cape-overlays Feb 09 20:07:43 I thought so, let me seek in the device tree Feb 09 20:08:05 since if remoteproc-pru has been added in mainline, then it's probably enabled in the main dt unless rcn patched that out Feb 09 20:08:17 I see Feb 09 20:08:19 or, maybe not enabled but at least declared Feb 09 20:11:59 yeah looks like added in the main dt Feb 09 20:12:03 and status is "okay" Feb 09 20:12:08 so I can disable that old overlay and reboot Feb 09 20:12:40 I have a pruss_soc_bus@4a326004 in ocp, just like in the overlay Feb 09 20:12:47 and there are minor differences but look the same Feb 09 20:15:04 woot, 4.19-ti uio-pruss works on the beagleboard-x15 Feb 09 20:15:47 need to do some shopping, then test on the beaglebone, and post it on the list Feb 09 20:15:57 nice Feb 09 20:16:06 ok still the same error in dmesg Feb 09 20:16:12 so the overlay was indeed superfluous but correct Feb 09 20:16:22 clk already disabled business Feb 09 20:16:26 but I'm gonna try the latest rc first Feb 09 20:16:27 in case anyone wants it => https://github.com/mvduin/ti-linux-kernel-dev/tree/ti-linux-4.19.y-uio-pruss Feb 09 20:16:51 (bbx15 tested, bbone not yet tested) Feb 09 20:27:34 UIO isn't enabled in the rcn kernels by default ? Feb 09 20:27:37 that's strange Feb 09 20:27:41 CONFIG_UIO is false Feb 09 20:28:01 so UIO_PRUSS is disabled too Feb 09 20:28:15 I'll build it to see what happens Feb 09 20:28:43 it's enabled in 4.19 Feb 09 20:28:53 I doubt 5 has been given any real attention yet Feb 09 20:29:06 yeah Feb 09 20:29:19 assuming it ever gets any... normally only LTS kernels matter Feb 09 20:31:08 using anything newer than 4.14 should be considered experimental, and anything newer than 4.19 as highly experimental Feb 09 20:31:27 anyway, bbl Feb 09 20:31:32 alright Feb 09 21:33:04 pizza! Feb 10 02:35:46 https://docs.px4.io/en/flight_controller/beaglebone_blue.html is another thing I found. Feb 10 02:42:53 Fly Blue Fly! Feb 10 02:51:11 Has anyone ventured to a Maker Faire w/ their BBBs (and other variations) to support the cause of Open Source ideas or to learn about other communities? Feb 10 02:52:01 ... Feb 10 02:55:26 If I am using eqep PRU_E_B from E4 on the BBBlue, would I need a voltage level shifter if battery (+/-) goes to receiver and the eqep line goes to receiver? The three lines are two from the battery and one from the eqep on the BBBlue that all go to the receiver. Feb 10 02:58:57 yes Feb 10 02:59:06 No way. Feb 10 02:59:09 Are you serious? Feb 10 02:59:10 also, eqep? why eqep? Feb 10 02:59:30 It automatically understands sBus or something like that. Feb 10 02:59:51 sbus requires an inverter and needs to be connected to an uart input **** ENDING LOGGING AT Sun Feb 10 02:59:56 2019