**** BEGIN LOGGING AT Thu Nov 19 02:59:59 2020 Nov 19 03:19:27 pretty first! Nov 19 03:24:02 I know one big cap has been done but for motors sake, what should I try? Nov 19 03:50:20 Someone once said, "Make a Cape." I forget where i was or who I was speaking to at that moment but...Cape Making in the process! Nov 19 03:51:03 Just something your .org can turn down but it will be the effort that counts. Boy! Nov 19 08:38:59 p Nov 19 10:40:54 Hello Nov 19 12:55:22 bah, yea, not what i was seeing. the backlight is working as expected, but the custom cape i made and my custom dtb is failing to register that it needs to output pixel data. Nov 19 13:26:12 bahhhhhhhhh, finally got it to work. Nov 19 13:26:53 turns out the dts files in the repository are outdated with regards to the ti,tilcdc and fb drivers. Nov 19 13:27:37 i needed to tweak the sections to match what the up to date documentation about the drivers has, and it now works. Nov 19 13:28:15 mainly it was moving the enable pin around, and removing extraneous variables in panel-info. Nov 19 13:28:39 now to tweak colors/porch size Nov 19 14:04:16 set_ 1 all the time, that's how I used FreeCAD to compare the boards in the image you saw in zee blog Nov 19 14:28:25 set_ if you want to generate the net list for a KiCAD schematic Tool->Generate Netlist File select the output type and click the generate button. Nov 19 14:51:16 Hi,i want to enable wake on lan on beaglebone can someone suggest me how i can do ? Nov 19 15:09:51 ooh that's interesting Nov 19 15:10:02 i'm curious as well pankajj Nov 19 15:28:42 I'm not sure that's really possible... the closest you might be able to get is entering suspend and waking up on any unicast to your MAC address received (though I don't know what would be involved in making that happen), but I don't recall the ethernet subsystem having any support for detecting WoL packets Nov 19 15:31:16 (or rather, any packet that passes whatever MAC/vlan based filtering rules have been set up) Nov 19 15:33:37 do you know any specific command related with it ? Nov 19 15:40:40 what do you mean by "it" ? I have no reason to believe any support for wakeup based on ethernet traffic has been implemented in software, and I'm not even sure it's supported in hardware. I am however fairly certain that _proper_ wake-on-lan (using detection of WoL "magic packets") is not supported in hardware (it would require a phy that supports this and able to trigger a wakeup gpio) Nov 19 15:52:14 I'm writing a bash script and I want to check if it is running on a Beaglebone Black or a Beaglebone AI. Does anyone know of an easy way to do this from the command line? Nov 19 15:52:47 yea, wol is very hardware dependant, unless it is okay to "turn off backlight until X packet comes in " Nov 19 15:53:04 "ps -e" Nov 19 15:53:23 hunter2018[m]: check /proc/device-tree/model Nov 19 15:53:50 ps = show all running programs, -e for all running on all users Nov 19 15:54:17 Konsgnxx: ... and how would that be helpful? Nov 19 15:54:54 oh I see how you parsed that question Nov 19 15:55:40 Thanks! Nov 19 20:10:25 how long does it take for bbai to boot from SD Nov 19 20:10:34 1 minute Nov 19 20:10:43 i am used to the flash Nov 19 21:11:14 basically reading from r31 is the same for PRU0 and PRU1, and PRU0_PRU1_INTERRUPT or ARM_PRU1_INTERRUPT will set bit 31, PRU1_PRU0_INTERRUPT or ARM_PRU0_INTERRUPT will set bit 30, right? Nov 19 21:23:32 (I meant with the default prussdrv intc mapping) Nov 19 21:25:33 bits 30-31 of r31 are the same for both cores, and show irq outputs 0-1 of the intc Nov 19 21:25:50 whats the difference between dtb vs dtbo Nov 19 21:25:58 dtbo is an overlay Nov 19 21:26:11 essentially a "patch" for a dtb Nov 19 21:29:36 mm302: reading r31 in general isn't the same for both cores though, just bits 30-31 Nov 19 21:29:42 Hello, does the ProtoCape work w/ the AI for the Compatibility Layer? Nov 19 21:31:20 isnt the protocape blank? Nov 19 21:32:24 let's say PRU 1 sees bit 31 set, in the simple case you know who sent the interrupt, but I'm wondering if it's possible to detect the source PRU0 or ARM as some information seems lost with the mapping Nov 19 21:32:43 Yes. But it has a LED, RGB LED and some buttons. Nov 19 21:33:23 I was going to try to use PWM from Bone Buses on the AI w/ that Cape but the AI does not boot once the Cape is in place. Nov 19 21:34:02 And...when I started to install the Comp. Layer, the BBAI just fails to boot. Nov 19 21:34:18 I am reflashing now. Nov 19 21:34:46 with the compatibility layer does it auto detect capes Nov 19 21:35:11 No. You have, well I thought, to install the dtbo in /boot/uEnv.txt. Nov 19 21:35:36 for instance, on the PWM, i2c, or in another way w/ another peripheral. Nov 19 21:35:37 actually looking at the SECR1 register it's possible to see which source interrupt was triggerd Nov 19 21:36:24 I will try to contact lorforlinux and see what is going on. Nov 19 21:38:10 ok Nov 19 21:38:22 but your compatility layer works ? Nov 19 21:38:29 what is your image and kernal Nov 19 21:41:06 I am flashing a new testing image now. Nov 19 21:41:12 I could not get it to work yet. Nov 19 21:42:36 brb Nov 19 21:53:12 Well, the reflash worked. This is nice. Nov 19 21:53:16 Off to test. Nov 19 21:59:18 well, I still do not see my pwm peripherals in the /dev/_______/ dir. Has anyone got this PWM idea to work on the BBAI yet? Nov 19 21:59:31 pwm is not even listed in /dev/. Nov 19 21:59:45 Is there a new location for the pwm peripherals? Nov 19 22:00:39 when I tried the install the comaptiblity it would not boot after I copied in the device tree Nov 19 22:04:04 Right. Same here. Nov 19 22:04:52 Supposedly, it is just supposed to work in the testing images. I think the kernel matters. Let me upgrade. Nov 19 22:05:23 how do you update the kernel Nov 19 22:05:25 to 4.19 Nov 19 22:06:12 you use the script someone produced. Nov 19 22:06:21 it is in /opt/scripts/tools/ Nov 19 22:06:54 Try, the 5.4.x kernel or anther one. I am trying the bone-channel one right now. Nov 19 22:07:14 --lts-5_4 --bone-channel. Nov 19 22:07:57 ok let me know if you get it to work Nov 19 22:08:14 In the overlays section, they have ideas on https://github.com/beagleboard/bb.org-overlays Nov 19 22:08:17 Okay. Nov 19 22:10:18 Nope. Upgrading kernels on the AI stops it from booting. Nov 19 22:10:25 Sheesh. Nov 19 22:11:09 Do not use the --bone-channel Nov 19 22:12:11 lol Nov 19 22:12:11 ok Nov 19 22:12:50 It may work for the 5.4.x kernel but w/ --ti-channel. Nov 19 22:12:54 I will test it. Nov 19 22:32:09 the --ti-channel boots w/ 5.4.x! Nov 19 22:32:44 ok Nov 19 22:33:19 This is good news. Now, it is time to test PWM. Nov 19 22:34:31 * GenTooMan watches set_'s home vibrate as he tests PWM Nov 19 22:35:51 Bzzt, bzzt! Nov 19 22:36:20 * set_ I am watching as my mind incorporates the home vibrations w/ my mind vibes. Nov 19 22:44:29 set_: the recommended kernel on the AI 4.14-ti (if using TIDL) or 4.19-ti (otherwise) Nov 19 22:44:39 and -bone kernels are indeed not compatible Nov 19 22:45:24 Right-o. Nov 19 22:45:38 using a 5.4-ti kernel is probably not a good idea Nov 19 22:45:53 I understand but I thought the 5.4 kernel is supposed to work w/ the Comp. Layer. Nov 19 22:46:00 "out-of-the-box" Nov 19 22:46:05 have you played with the compatibility layer zmatt Nov 19 22:46:31 nope, but it seems unlikely it requires a 5.4 kernel Nov 19 22:47:41 since 1. there's no logical reason for this 2. it would make it a whole lot less useful since 5.4 is not the kernel used on current images nor on the latest testing images Nov 19 22:51:08 Okay. Nov 19 22:51:15 I will downgrade right now to 4.19. Nov 19 22:51:31 Just to see if the /dev/pwm/ dir. exists. Nov 19 22:51:54 It did not work w/ the 5.4.x kernel for some reason. Nov 19 22:52:01 But... Nov 19 22:52:12 The board boots and works w/ that specific kernel. Nov 19 22:53:44 Is this a live chat where I can get help with beaglebone black? Nov 19 22:54:06 yes Nov 19 22:54:06 it's a community chat for beaglebone users Nov 19 22:54:23 Can someone help me with flashing the latest debian image on my beaglebone black? Nov 19 22:55:08 I've been trying for literally 6 hours and I don't know what I'm doing wrong Nov 19 22:55:20 which image did you download? Nov 19 22:55:53 The second one of the latest ones. The one for beaglebone black Nov 19 22:55:53 AM3358 Debian 10.3 2020-04-06 4GB SD IoT Nov 19 22:57:01 so, the "SD" means the image is intended to just boot from sd card, it won't automatically reflash eMMC. for that you can either use an eMMC Flasher image, or you can change your SD image into an eMMC flasher by changing 1 line in a config file Nov 19 22:58:51 Yeah I changed the uEnv.txt file Nov 19 22:59:19 so what are your symptoms exactly? Nov 19 23:00:26 I go through the whole process of flashing. I put the microSD in, power on the board while holding the boot button and the lights flash in a cycle then all turn on then off. I unplug the BB and take out the SD card. I check the Debian version, and it still says it is the old version and not the new one Nov 19 23:00:41 So basically, it goes through the whole flashing process, but doesn't say it is updated to the new image Nov 19 23:01:08 that's fascinating Nov 19 23:01:50 But now that you mention it, I can try downloading the other debian version that is meant to flash. I didn't know there was a difference, I am new to this. Nov 19 23:01:58 After trying that, can I contact you through here again? Nov 19 23:02:53 this may sound like a weird question but I'm just curious: did you end up modifying uEnv.txt twice? like, you did the change but later the change seemed to be gone? Nov 19 23:03:33 I did, but I realized that meant the text file didn't save. I confirmed it was saved by doing the change and rebooting the system and checking if it was still edited Nov 19 23:03:57 since something I know has happened to some people is that they _thought_ they booted from SD card but in fact had booted from eMMC, so they ended up modifying /boot/uEnv.txt on eMMC instead of on SD Nov 19 23:04:17 which I think causes eMMC to turn into a flasher that reflashes the SD card Nov 19 23:04:23 I have been doing sudo nano /boot/uEnv.txt Nov 19 23:04:26 oh that's strange Nov 19 23:04:30 So what should I do? Nov 19 23:04:39 Maybe I did do that without realizing Nov 19 23:04:39 it's just the same logic, but with the devices swapped Nov 19 23:04:51 so now you have an SD card with your old system flashed onto it Nov 19 23:05:17 Hmm that makes sense. Okay I'll try reformatting the SD card and then flashing it with the "flasher" version of the debian image Nov 19 23:05:29 the big question is: why didn't it boot from the sd card initially Nov 19 23:05:35 usually that indicates it was flashed incorrectly Nov 19 23:05:44 Probably, this is my first time attempting this Nov 19 23:05:47 are you using Etcher ? Nov 19 23:05:57 Yes, balenaEtcher Nov 19 23:06:21 strange, that should definitely work correctly Nov 19 23:06:46 anyway, best bet is to reflash the SD card with the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" and try again Nov 19 23:08:50 Yes that's the one I am downloading now Nov 19 23:09:15 got git I need to change the branch before pulling irght Nov 19 23:09:25 Should I check the uEnv.txt on my board? Nov 19 23:09:27 or when I do a clone i get everything Nov 19 23:10:05 Aceplosion: if you use a Flasher image you don't need to do anything with /boot/uEnv.txt Nov 19 23:10:22 when it boots from the SD card it will automatically proceed to reflash eMMC Nov 19 23:10:32 zmatt It won't flash the SD card again? Nov 19 23:10:47 not unless you mess with /boot/uEnv.txt on eMMC again Nov 19 23:11:31 also, if you hold the S2 (boot) button during power-up (you can let go once the power led turns on) then eMMC is completely ignored Nov 19 23:11:40 Oh okay Nov 19 23:12:30 (this is usually not necessary to boot from sd card, but it can be needed if the system on eMMC is really ancient or weird, and it doesn't hurt to do it anyway to make sure the contents of eMMC is ignored) Nov 19 23:12:33 So basically I just flash the SD card again, put it in the unpowered BB. Then, plug in my USB while holding the S2 button and let it go through the flashing process and it should work Nov 19 23:12:58 Yeah I probably need to because I probably messed with the uEnv.txt file Nov 19 23:13:00 you can let go as soon as any led turns on Nov 19 23:13:31 Also the image current image on it is 2016-01-24 Nov 19 23:14:26 so, here's a way to be extra sure that eMMC is bypassed (the tiny button can be fiddly): initially power it on with S2 button held down but without any SD card inserted. the result should be that the BBB fails to boot entirely: apart from the power led there should be no LED activity (since eMMC is bypassed and it has nothing else to boot from) Nov 19 23:14:41 then, without disconnecting power, insert the SD card and press the reset button Nov 19 23:15:08 that way you're absolutely 100% sure it's not booting from eMMC Nov 19 23:15:18 You think I should do that instead? Nov 19 23:15:57 so I just tried the comp layer thing and it blocks booting Nov 19 23:16:16 I don't know... if you turned eMMC into a flasher again then it might be wise. then again, it sounds like you're able to log into the system currently, which means it's _not_ a flasher currently Nov 19 23:16:20 this is on kernel 4.14 on a fresh install all I do is follow the directions on the GSoC Nov 19 23:16:34 the only thing I could of messed up is the git clone Nov 19 23:16:34 Aceplosion: or even if you did, it should prefer to boot from SD card anyway Nov 19 23:16:49 Aceplosion: so no, on second thought it's probably overkill :P Nov 19 23:17:21 mattb000ne: git clone of what? Nov 19 23:17:33 Hmmm that's quite strange to me Nov 19 23:17:42 Aceplosion: what is? Nov 19 23:17:44 I really don't want to mess this up again, can you tell me the exact process I should do then Nov 19 23:18:16 following these instructions Nov 19 23:18:17 https://deepaklorkhatri.me/GSoC2020_BeagleBoard.org/2020/07/19/installing-compatibility-layer/ Nov 19 23:18:27 That the system isn't a flasher, because that's the only thing I can think of for what happened to my SD Nov 19 23:18:29 his github Nov 19 23:18:52 Aceplosion: really, like 99% of the time it should suffice to just write the flasher image to SD and boot from it Nov 19 23:19:20 it should do the knight rider thing with the LEDs Nov 19 23:19:23 Aceplosion: right, so that's why I asked if you ended up modifying /boot/uEnv.txt twice: I think you first changed eMMC into a flasher and flashed your old system onto SD card, and then changed your SD card into a flasher and flashed that back onto eMMC Nov 19 23:19:30 takes a bit to get going though from what I remember Nov 19 23:20:39 Aceplosion: so the end result is eMMC being essentially the same as it was before all this, and you have an SD card that flashes your old system onto any beaglebone :D Nov 19 23:21:38 so I just turn on the board with the sd card in? Nov 19 23:22:03 if the SD card is bootable that should normally suffice yes Nov 19 23:22:26 holding the S2 button during power-on is optional but in very rare cases helpful (and never harmful) Nov 19 23:23:39 Hmm okay, I'm trying now Nov 19 23:23:52 etcher is flashing it to the sd now, i'll let you know how it goes Nov 19 23:24:09 This may seem like a weird question, but how do I reset a BB to factory Nov 19 23:25:19 reflashing it Nov 19 23:25:36 With whatever debian image came on it? Nov 19 23:25:54 whatever debian came on it is arbitrary, depends on when the BBB was manufactured Nov 19 23:26:17 I'd generally recommend reflashing any newly purchased BBB Nov 19 23:27:27 Hmm okay Nov 19 23:27:38 So, I put the SD card on the board Nov 19 23:27:43 in the board* Nov 19 23:27:51 If I plug it in, it should work right? Nov 19 23:28:17 it should proceed to reflash eMMC yes Nov 19 23:28:44 so after a bit of startup delay you should get the "knight rider" back-and-forth led pattern and it should turn itself off when done Nov 19 23:29:30 kit lives Nov 19 23:29:38 *kitt Nov 19 23:29:46 is it two t's Nov 19 23:29:47 lol Nov 19 23:30:03 anyways zmatt did you peak at lorforlinux instructions Nov 19 23:30:11 should I have changed my branch or something Nov 19 23:30:24 no, I was distracted by a cool youtube vid about holograms Nov 19 23:30:46 zmatt I put in the SD card and I powered it on, but it is just doing the "heartbeat" pattern with the one led Nov 19 23:31:46 interesting Nov 19 23:32:22 maybe the bootloader on eMMC is actually too ancient to boot the sd card. try again but this time hold the S2 button (the button closest to the SD card slot) while connecting power Nov 19 23:32:38 Should I reflash the SD card before doing that just in case? Nov 19 23:32:41 you can let go once the power led turns on (or I think you technically need to hold it for 0.025 seconds or something) Nov 19 23:33:08 nah, you didn't see any flasher activity, it just booted a normal system evidently Nov 19 23:33:26 which has to be the one on eMMMC since you put a flasher on the SD card Nov 19 23:33:39 (you did right?) Nov 19 23:34:11 Yes, I put the flasher on the SD card Nov 19 23:35:24 Okay I tried it again while holding the S2 button and it is doing the led effect now Nov 19 23:35:48 gotcha Nov 19 23:35:50 So I'll update you when it's done Nov 19 23:36:16 Is there anywhere I can get a hold of you if I need help again some other time? I don't want to bother you, but you've been incredibly helpful Nov 19 23:36:42 so, mystery solved probably: initially you thought you booted from SD card but you didn't because the bootloader on eMMC is too ancient to be compatible (and you either didn't hold the S2 button at power-up, or at least didn't do so successfully) Nov 19 23:36:58 so then you thought you edited /boot/uEnv.txt on the SD card, but it was in fact on eMMC Nov 19 23:37:36 then you booted from eMMC again, which was now a flasher that reflashed your SD card into the old system Nov 19 23:38:00 this made it compatible with the ancient bootloader on eMMC, so next time you did actually boot from SD card Nov 19 23:38:35 woah Nov 19 23:38:37 then you were puzzled about /boot/uEnv.txt seemingly having reverted, and edited again, but this time on the SD card Nov 19 23:39:22 :) Nov 19 23:39:31 -Hmm I agree that is probably what happened Nov 19 23:39:37 I'll update you when the flashing is done Nov 19 23:39:48 I check by doing cat /etc/dogtag Nov 19 23:39:56 and this channel is the best place to find me Nov 19 23:40:01 Okay that's cool Nov 19 23:40:16 When the lights turn on do I take out the sd card and then unplug it Nov 19 23:40:23 Or do I unplug and then take out sd card Nov 19 23:40:24 yep Nov 19 23:40:31 whichever, it'll be turned off already Nov 19 23:41:20 and once you've confirmed you've successfully reflashed your BBB, maybe wipe your sd card on your computer so you don't forget it contains a flasher and accidently boot the BBB from it again Nov 19 23:41:26 (which I'm quite sure has happened to people) Nov 19 23:42:30 Okay so the lights turned off Nov 19 23:42:39 If I plug in my BB again it should be fine right? Nov 19 23:43:13 And thank you for that advice Nov 19 23:43:34 yep. remove card, power-cycle the board, and it should boot into your new debian system Nov 19 23:43:42 so zmatt Nov 19 23:43:50 any thoughts on that comp layer business Nov 19 23:43:54 right, sorry Nov 19 23:45:32 try using kernel 4.19-ti and branch v4.19.x-ti-overlays Nov 19 23:46:06 you can choose the branch when cloning using the "-b v4.19.x-ti-overlays" option or you can switch branch on the already-cloned repository using "git checkout v4.19.x-ti-overlays" Nov 19 23:46:42 ok Nov 19 23:46:51 thank you sir Nov 19 23:46:57 goofing off for the holidays Nov 19 23:47:25 Oh yeah I think you nailed it earlier @zmatt about me making the board a flasher because now I remember when I first flashed it the board was unresponsive and didn't have leds on or anything and I was scared so I tried reflashing it and that's probably when I began looping the images back and forth Nov 19 23:48:34 Omg it finally worked Nov 19 23:48:38 Thank you so much zmatt Nov 19 23:48:44 :D Nov 19 23:56:45 So what can I do with a new image haha Nov 19 23:56:58 I'm new to this zmatt so I'm still learning the basics Nov 19 23:57:09 Is putty good to access the board? I've been using putty com5 Nov 19 23:58:15 you'll usually want to connect via ssh rather than to the serial console, since the serial console is really slow and a bunch of things don't work right (like resizing the window)... putty can do both Nov 19 23:59:44 ssh access also works when the beaglebone is connected to your local network (via ethernet in case of the BBB, or via wifi for beaglebone variants with wifi) Nov 20 00:01:02 (though the IP address won't be 192.168.7.2 in that case but will depend on your local network situation, connecting to the beaglebone by hostname "beaglebone" or "beaglebone.local" may work in that case depending on host OS and again local network situation) Nov 20 00:02:32 So... Nov 20 00:03:06 git checkout v4.19.x-ti-overlays goes where for the Comp. Layer? Nov 20 00:03:26 Once I clone the repo. and before make? Nov 20 00:03:46 set_: like I said you can use that to switch branch if you've already cloned Nov 20 00:03:54 Okay. Nov 20 00:04:10 I will try it. I have been unable to get the /dev/bone/pwm to show just yet. Nov 20 00:04:11 if you haven't cloned yet you can instead specify the branch using the "-b v4.19.x-ti-overlays" option to git clone Nov 20 00:04:21 Oh. Okay. Nov 20 00:04:25 the end result is the same either way Nov 20 00:05:18 So, will that ensure that /dev/pwm/ or /dev/bone/pwm/ will show up? Nov 20 00:05:58 or...do I then need to get bb.org-overlays for that particular purpose? Nov 20 00:07:20 dunno, haven't fiddled with it... creating symlinks is the job of udev rules, which are part of the bb-customizations package Nov 20 00:07:27 so maybe make sure that package is uptodate Nov 20 00:08:08 Okay. Nov 20 00:23:17 I mean, maybe i got it to work already b/c i2c shows in /dev/bone/ Nov 20 00:23:47 I just need to attach a Cape or something. I am guessing here but I think that the ProtoCape is not yet working w/ this Comp. Layer. Nov 20 00:30:00 set_ can you create an issue under devicetree repo regarding the problem you are facing with compatibility layer? Nov 20 00:30:32 sure. so, github.com/beagleboard.org/device-tree? Nov 20 00:31:20 I found it. Nov 20 00:31:30 There is currently only one issue so far? Nov 20 00:32:02 https://github.com/beagleboard/BeagleBoard-DeviceTrees Nov 20 00:32:17 +lorforlinux[m]: Right. I found it. I will create an issue. Nov 20 00:32:48 I think I may need to provide some info. to you or whomever. What info. are you guys going to need? Nov 20 00:33:08 for instance, version.sh or another form of log file/ Nov 20 00:34:07 Whatever required to replicate and resolve the problem is fine to attach with the issue. Nov 20 00:34:30 Okay. Nov 20 00:34:44 I am flashing a new image and I will workout the steps to reproduce the issue. Nov 20 00:34:44 Please make sure your board is running uptodate version of compatibility layer. Nov 20 00:34:49 https://deepaklorkhatri.me/GSoC2020_BeagleBoard.org/ Nov 20 00:34:49 Okay. Nov 20 00:35:10 Follow the instructions I have provided on the main page. Nov 20 00:35:14 Okay. Nov 20 00:36:33 It should be easy to follow just click on the copy button and paste on you beaglebone terminal. Nov 20 00:36:38 Okay. Nov 20 00:38:26 +lorforlinux[m]: Does the layer create a pwm peripheral somewhere, i.e. /dev/bone/i2c/? Nov 20 00:39:30 or /dev/pwm? Nov 20 00:40:09 The reason I am asking is b/c I was going to just test it w/ a regular LED, i.e. fading. Nov 20 00:40:32 Nope things changed, you have to manually do that. iirc after a update in a pwm udevrules it doesn't load automatically. Nov 20 00:40:56 The update was necessary for pocket beagle i think 🤔 Nov 20 00:41:15 Okay. Nov 20 00:41:39 So, each time, I need to update the layer w/ a command? Nov 20 00:41:40 Set ? Nov 20 00:41:47 KenUnix! Nov 20 00:41:53 Welcome back ole timer! Nov 20 00:42:05 I might have some instructions for doing that pwm thing manually don't know where, will update here if I find it. Nov 20 00:42:19 You are not updating the layer Nov 20 00:42:25 KenUnix: +lorforlinux[m] and I are trying to hash some things out on the Comp. Layer. Nov 20 00:42:26 Oh. Nov 20 00:42:27 Okay. Nov 20 00:42:38 No updating the layer, got it. Nov 20 00:42:49 Yeah Nov 20 00:43:16 You just export the PWM channel manually. Nov 20 00:43:28 so it is this, get the correct image, update kernel and update bootloader? Nov 20 00:43:30 Layer just enables the PWM Nov 20 00:43:38 Right, but where are the pwm channels? Nov 20 00:43:49 I just stopped by to let you know due to medical reasons I am terminating my Linux work. I tried emailing you but the address is no longer via or. Nov 20 00:43:52 I could not find them. Nov 20 00:44:03 Oh. KenUnix. Nov 20 00:44:07 Get the recent image and follow the steps Nov 20 00:44:17 I am sorry. I scraped that email. SOrry. Nov 20 00:44:20 Okay. Nov 20 00:44:32 +lorforlinux[x]: Okay. Nov 20 00:44:39 x = m Nov 20 00:44:41 Sorry. Nov 20 00:44:41 Valid Nov 20 00:44:50 Valid Nov 20 00:44:59 KenUnix: What is wrong w/ health these days? Nov 20 00:45:11 You got COVID-19? Nov 20 00:45:45 I am he Nov 20 00:46:36 I am having kidney and lung problems Nov 20 00:46:46 Kidney! Nov 20 00:47:01 Dialysis? Nov 20 00:47:08 I am sorry. Nov 20 00:47:16 Yes I only have 1. Nov 20 00:47:20 Damn.a Nov 20 00:47:45 Did they tell you to get outside more or get Sun? Nov 20 00:48:01 If you email me I will save your address. Nov 20 00:48:08 Crispy vitamin D? Nov 20 00:48:09 Okay. Nov 20 00:48:21 I will email you. Nov 20 00:49:26 High bun causing cut. Nov 20 00:49:41 set_ chapter 9 of exploring beagle bone is what you need after installing the compatibility layer correctly. Singing off for now 👍 Nov 20 00:49:51 High bum causing cut. Nov 20 00:49:58 Okay. Nov 20 00:50:12 Thumbs up, dude. Nov 20 00:50:25 KenUnix: High bum? Nov 20 00:50:42 Lung problems causing cold. Nov 20 00:50:45 Oh. Nov 20 00:50:47 No! Nov 20 00:50:52 That sounds terrible. Nov 20 00:51:02 Now, it is going to be freakin' winter soon. Nov 20 00:51:59 My pc has been off for a week. I am on a tablet now. Nov 20 00:52:37 Oh. Nov 20 00:53:01 Amazon fire 10 Nov 20 00:53:11 lorforlinux[m]: I tried the instructions on the page and it did not work Nov 20 00:53:15 i have tried it 4 times Nov 20 00:53:18 I have been caught up in this idea of promoting heavy motors w/ a big ball screw w/ spindle. Nov 20 00:53:23 i am non kernal 4.14 Nov 20 00:53:57 KenUnix: what are you going to do w/ time and effort? Nov 20 00:54:10 ALl the work you put in and time and effort, I mean? Nov 20 00:55:04 Bye for now. 'W / time effort' ?? Nov 20 00:55:08 Amazon Fire tab, ha. You have to push the buttons on teh screen? Nov 20 00:55:31 Time and effort w/ the basicbw? Nov 20 00:56:11 Supposedly, the BBAI can handle the Cape for basicbw w/ a abstraction layer now. Nov 20 00:56:24 I am still trying but you know me, I am slow to go. Nov 20 00:56:45 Yes touch screen or Alexa. Got no interest in it. Turned over to Jon Foster. Nov 20 00:57:27 Oh. Nov 20 00:57:28 Okay. Nov 20 00:57:47 Well mate, I hope you heal and stay on your heels. Nov 20 00:58:03 I remember we chatted about health a couple of times. Nov 20 00:58:16 Scary stuff plus w/ COVID, it is even scarier. Nov 20 01:01:29 bbl! Nov 20 02:21:50 +lorforlinux[m]: I set up the issue in github for the BeagleBoard-DeviceTrees. Nov 20 02:31:00 Hey zmatt are you still there? Nov 20 02:48:34 Well...I think I figured it out! Nov 20 02:48:58 uEnv.txt file under /boot/ needs to have the .dtb loaded, i.e. not empty. Nov 20 02:49:07 Forget the dtbo for now. Nov 20 02:49:35 I added the dtbo too under external capes just to make sure I did not know what I was doing. Nov 20 02:49:47 So, it is either one or two or both. Nov 20 02:50:11 but...the pwmchip0 showed its pretty face! Nov 20 02:54:18 But...it seems the pwmchip0 is something that needs ________? GenTooMan? Nov 20 02:55:16 I do not even know if I can use pwmchip0 b/c I have not a reference for where pwmchip0 handles what pins on the BBAI. Yaml. **** ENDING LOGGING AT Fri Nov 20 02:59:57 2020