**** BEGIN LOGGING AT Thu Apr 23 02:59:58 2020 Apr 23 03:00:00 since they don't account for the fact that read(fd,response,2) might just read a single byte and return Apr 23 03:00:19 zmatt lots of whats to do what? Apr 23 03:00:21 hold on, lemme cook up some examples Apr 23 03:00:30 ok Apr 23 03:00:45 CCS10 was "managing" the build configuration for me, thank you very much. Turned that off, selected what I needed, BAM, works! Thank you very much! Apr 23 03:00:55 biggi_: sorry, I meant MattB0ne / mastermind_ Apr 23 03:01:08 @zmatt that was to you Apr 23 03:01:18 gotcha, i just saw it and i was thinking "uhhh" Apr 23 03:01:27 biggi_: yeah apologies Apr 23 03:01:36 I was just failing at multitasking Apr 23 03:02:13 is all good! but yea i'll keep you updated on the cam stuff then on the quad encoder stuff. got me some quad to single ended chips you recommended and i'm going to go to town Apr 23 03:05:05 man my internet sucks Apr 23 03:05:21 everyone in the workd stop watching Tiger King on Netflix! Apr 23 03:06:13 zmatt any luck with the example? Apr 23 03:07:19 MattB0ne: patience :P Apr 23 03:13:39 sorry Apr 23 03:18:41 MattB0ne: https://pastebin.com/cDA84WQu Apr 23 03:19:01 so, the die() function is just a crude way to handle errors (print and exit) Apr 23 03:19:13 you can replace it with whatever error handling you prefer Apr 23 03:19:39 read_full() is a wrapper around read() that reads _exactly_ the number of bytes specified (or dies if it can't) Apr 23 03:20:06 that's the bit the example in the jrk doc failed to do Apr 23 03:21:14 read_u16_v1 is the same as what their C example does, read_u16_v2 is another way that looks nicer but is less portable (but honestly who cares about big endian systems these days) Apr 23 03:22:26 replacing uint16_t by int16_t in read_u16_v2 would yield a variant that reads a signed 16-bit integer, but you can also just read an uint16_t and cast it to int16_t, which is what read_s16() does Apr 23 03:33:40 Out of curiosity, have you all thought about moving the IRC to Discord or something? Apr 23 03:34:22 ew Apr 23 03:34:37 I'll take that as a no XD Or a Slack or something? Apr 23 03:37:15 I think the fact that they'd lose me would be reason enough to stop them from considering doing so, since I'm probably a single biggest contributor here Apr 23 03:37:47 Haha true. I take it you're anti Slack/Discord Apr 23 03:37:49 MattB0ne: even more ways to do the same, just for fun ;) https://pastebin.com/N1BddiPx Apr 23 03:38:30 MattB0ne: all except _v1 assume the host is little-endian. it would be easy enough to fix the code to be endian-independent but I just don't care about big-endian systems so I'm not going to bother Apr 23 03:40:39 biggi_: irc works perfectly fine for the task, is an open standard that has been around for ages with numerous clients that to suit anyone's tastes Apr 23 03:42:03 and my irc client is something I have running in an unobstrusive terminal window sitting in a corner of my screen. if it were in a browser tab then I just wouldn't look at it Apr 23 03:43:00 and there are lots of technical irc channels for open source projects on freenode Apr 23 03:43:13 so I would be here on irc anyway Apr 23 04:03:28 thanks zmatt! Apr 23 04:04:11 zmatt: Thanks! Apr 23 04:10:35 If anyone is out there, how can I make my file realize where my pocketsphinx.c file is in my file system. I tried w/ export and notta. Apr 23 04:11:04 I cp'd the .h file to /usr/include/ too. Apr 23 04:11:47 please remove that and never do that again Apr 23 04:11:55 Okay. Apr 23 04:12:27 (I'm not in the mood for trying to figure out what it is you're trying to do, but I did want to say that) Apr 23 04:12:44 Okay. No issue. Apr 23 04:14:08 Sorry. I put it in /usr/local/include. Apr 23 04:16:30 why are you bothering with source code at all? if you want to write C applications that use libpocketsphinx (which already seems odd but okay) just sudo apt install libpocketsphinx-dev Apr 23 04:17:12 there are also python3 bindings, sudo apt install python3-pocketsphinx Apr 23 04:19:20 Okay. I already got the pocketsphinx system up and running. I am trying to compile a .c file w/ a preprocessor directive of #include but it is not being recognized in my file system, e.g. not even w/ find / pocketsphinx.h. Apr 23 04:19:40 I will try your way. Apr 23 04:21:41 Just for reference, no matter where i put this .h file, the Debian distro is not finding it. Apr 23 04:22:08 set_: I have complete faith in assuming it's just you Apr 23 04:22:27 I know you already know it is 99.9% me but...heh? Apr 23 04:22:35 also stop copying files into random places before you break your system again Apr 23 04:22:43 Okay. Apr 23 06:47:07 Hi i have doubt that MAC address for LAN connection is individual one for each single board or same for all. Apr 23 07:06:23 what makes you doubt? Apr 23 07:15:15 $ sqlite3 -csv db.sqlite3 'select count(*), count(distinct mac_address) from beaglebone' Apr 23 07:15:18 1277,1277 Apr 23 07:16:11 (from our database of beaglebones) Apr 23 07:17:24 this in contrast to the serial number in eeprom :P Apr 23 07:17:25 $ sqlite3 -csv db.sqlite3 'select count(*), count(distinct serial) from beaglebone' Apr 23 07:17:28 1277,1276 Apr 23 11:26:41 m Apr 23 11:33:25 m2 Apr 23 13:38:08 Hello? Apr 23 13:38:56 I plan to buy a BBB Wireless. Is there any info or sample project for Bluetooth? Apr 23 13:39:04 :] Apr 23 13:40:50 Any friend out there? \O/ Apr 23 13:41:16 no Apr 23 13:41:21 dont get a wireless Apr 23 13:41:37 get a standard black or green beagle board Apr 23 13:42:02 I need bluetooth though Apr 23 13:42:29 plus a cellular modem Cape Apr 23 13:45:28 Well, if I want to develop IoT application, what language would you recommend to run a looping application? Apr 23 13:45:51 I can do Bash Script :] Apr 23 13:47:17 Not many BBB experts right now -_- Apr 23 13:51:47 zmatt knows everything but he is not here right now-_- Apr 23 15:13:43 Any BBB good man? :] Apr 23 15:14:22 Could you please show me BBB bluetooth library? Thanks. :] Apr 23 16:38:43 MattB0ne: "dont get a wireless" .. why not? Apr 23 16:39:29 the Green Wireless is awful, but there's nothing wrong with the Black Wireless if you want wifi/bt instead of ethernet Apr 23 16:46:25 zmatt: i thought since green and black are virtually the same that the wireless versions would be equally bad Apr 23 16:46:33 also since you are here Apr 23 16:46:44 I remember you mentioning that you are self taught Apr 23 16:46:50 nope, the black-wireless is fully bbb-compatible Apr 23 16:46:56 it's just the green-wireless that's awful Apr 23 16:47:12 if you were going to map out a self study program to pick up some of your know how Apr 23 16:47:17 what would it be Apr 23 16:47:34 I have no idea what that question even means, sorry Apr 23 16:48:29 I've never in my life "mapped out a self study program" Apr 23 16:50:32 doesnt have to be a program per se Apr 23 16:50:37 things you should know Apr 23 17:52:20 zmatt: posed another way how did you aquire your current knnowledge base Apr 23 17:52:33 what did you do when you first started out Apr 23 19:27:54 GenTooMan: in between the HC126 and HC04 on that circuit, would I need other circuitry, e.g. I know I need the cap(s) but would I need anything else to connect between the two chips? Apr 23 19:29:29 For instance...would it be possible to attach OE on the HC04 to the Input on the HC126? Apr 23 19:30:55 directly? I know about the voltage requirements. Both can operate at around 5v. Apr 23 19:33:09 Or...should I just operate w/out OE on the HC04 to the HC126. Then, I can use 1A and 1Y on the HC04 to the HC126. Sorry. There is no OE on the HC04. Apr 23 19:35:16 So, 1/2OE on the HC126 needs to be attached to the dc-dc converter. This way, I can attach it to the BBB for feeding 3.3v logic to the BBB for feedback? Apr 23 19:36:06 Just for reference, i am still using a circuit program to set up my circuit. Apr 23 19:54:49 i used to have remoteproc1 and remoteproc2 but now i only have remoteproc0 Apr 23 19:55:00 how to fix this error Apr 23 19:56:29 amine43: you asked this 3 days ago and I already explained what the problem was Apr 23 19:56:41 it still persists Apr 23 19:56:53 i uncommented the lines in /boot/uEnv.txt Apr 23 19:57:05 but still the same problem Apr 23 19:57:24 uncommented what lines? Apr 23 19:58:01 uboot_overlay_pru=/lib/firmware/AM335X-PRU-RPROC-4-4-TI-00A0.dtbo Apr 23 19:58:18 and commented uboot_overlay_pru=/lib/firmware/AM335X-PRU-UIO-00A0.dtbo Apr 23 19:59:14 okay, please run sudo /opt/scripts/tools/version.sh and share the output via pastebin.com (or some other paste service) Apr 23 20:00:33 https://pastebin.com/2gyk920m Apr 23 20:01:14 you're using kernel 4.9 but enabled the overlay for kernel 4.4 Apr 23 20:01:20 use the correct overlay for the kernel version you're using Apr 23 20:01:33 I already said that last time Apr 23 20:02:15 so i have to re-flash the card with kernel 4.4 ? Apr 23 20:02:24 no, use the correct overlay for your kernel version Apr 23 20:02:40 your system is already really old, don't make it even older Apr 23 20:02:49 how to do that ? Apr 23 20:04:02 should i upgrade to debian 9.5 ? Apr 23 20:04:32 the name over the overlay reflects the kernel version: AM335X-PRU-RPROC-4-4-TI-00A0.dtbo is for 4.4, AM335X-PRU-RPROC-4-9-TI-00A0 is for 4.9, AM335X-PRU-RPROC-4-14-TI-00A0 is for 4.14, AM335X-PRU-RPROC-4-19-TI-00A0 is for 4.19 Apr 23 20:05:16 set_ you need to test the circuit with the AX12 first Apr 23 20:05:43 if reflashing/upgrading is an option (i.e. if you're not already deeply invested in your current system) then I'd recommend reflashing to the latest image (from https://beagleboard.org/latest-images ), which is debian 10.3 and uses kernel 4.19 Apr 23 20:05:54 in uEnv.txt i only have the option for 4.4 Apr 23 20:05:56 ###PRUSS OPTIONS Apr 23 20:06:16 amine43: it's just giving examples, just change the file path Apr 23 20:06:25 also don't try to paste multiline text into chat, it doesn't work Apr 23 20:06:41 ah okay Apr 23 20:07:07 GenTooMan: I am not sure I understand. So, I set up the servo w/ the dc-dc converter first? Apr 23 20:07:09 i am still a newbie so i'am sorry Apr 23 20:07:10 what debian version are you using? (cat /etc/debian_version) Apr 23 20:07:45 9.12 Apr 23 20:08:21 okay... just making sure it's not debian 8 or something :P Apr 23 20:09:31 hahaha okay so upgrading to 10.3 iot will fix the problem ? Apr 23 20:10:01 remoteproc will work out of the box on any not-ancient system. it will have worked on your system as well, you just broke it Apr 23 20:10:08 (somehow) Apr 23 20:12:19 in the end it's up to you. if you invested a lot of time into customizing your image and building stuff on top of it then I guess it's not super-urgent to upgrade yet (although it *is* getting quite old). but if this is not the case, if you don't mind reflashing then I do very much recommend it Apr 23 20:12:33 I wouldn't *start* any project with a system this old Apr 23 20:12:49 i al trying to fix remoteproc so i can continue learning to use prus, i will be needing the prus to implement an MDB protocol using uart0 and i am new to linux ( i only know embedded c and some basic instructions and notions ) Apr 23 20:12:58 so i guess reflashing it is better Apr 23 20:13:14 uart0 is the serial console, it is in use Apr 23 20:13:22 unless you mean the pru uart Apr 23 20:13:29 in which case, call it the pru uart :P Apr 23 20:13:31 pru uart yes Apr 23 20:13:41 okay hahaha Apr 23 20:13:58 through the pru uart* Apr 23 20:14:34 so, the 9-bit stuff can probably done with the uart (by using "stick parity"). on the other than, it may actually be easier to just implement the serial protocol entirely in software, especially since MDB isn't particularly high-bitrate Apr 23 20:14:48 you'll just have to see which option seems more convenient to you Apr 23 20:14:57 neither should be particularly difficult I think for pru Apr 23 20:17:42 yeah searching the web i found out that the best solution is to use the parity bit as the 9th bit and try to dorce it either 1 or 0 but as i said i'am still new to all of this hhh so this is quite exciting Apr 23 20:19:07 also, to avoid having to hardcode remoteproc instance numbers (e.g. /sys/class/remoteproc/remoteproc1), which are not stable and can vary depending on kernel version, kernel config, and device tree, you may want to upgrade the bb-customizations package or manually update the udev rule to get named symlinks... lemme see if I can make newbie-proof instructions for this Apr 23 20:20:57 i would be glad if you do so because you lost me at device tree xD Apr 23 20:21:39 basically, there's nothing guaranteeing which entry in /sys/class/remoteproc corresponds to which device Apr 23 20:21:41 set_ 2 problems 1 I don't know what you did 2 you aren't using the original circuit and have deviated from it. I cannot say "yes" or "no" to something I know nothing about. Apr 23 20:22:15 so there's a new fix that lets you find the remoteproc device by name instead of just assuming it has a specific number Apr 23 20:24:31 what is this new fix Apr 23 20:24:39 on this website Apr 23 20:24:42 https://www.element14.com/community/community/designcenter/single-board-computers/next-genbeaglebone/blog/2019/05/14/coding-for-the-beaglebone-pru-with-c-in-2019 Apr 23 20:24:52 PRU0 - confusingly referred to a remoteproc1. (PRU1 is remoteproc2. remoteproc0 is to do with the Cortex M3 co-processor.) Apr 23 20:25:03 i found this Apr 23 20:25:21 yeah so that's wrong. pru0/1 _may_ be remoteproc1/2 but there's nothing guaranteeing this Apr 23 20:25:45 just hold on, I'm working on instructions Apr 23 20:26:00 okay take your time and thanks Apr 23 20:26:45 GenTooMan: Okay. I have the original circuit. I can put the circuit together. I have not put the Half Duplex circuit together yet. Apr 23 20:26:52 but first reflash to the latest image please, i.e. download the "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" image, write it to sd card using Etcher (https://etcher.io/), and boot the beaglebone from that sd card. it will automatically erase and reflash eMMC Apr 23 20:27:44 GenTooMan: I have all the components (I think) and I can make the circuit. Apr 23 20:27:59 okay i have already downloaded the image and i shall reflash it right now Apr 23 20:28:21 I need to check for the caps still. Apr 23 20:30:51 GenTooMan: sorry. I need to go. I will check back in later. Apr 23 20:36:39 sorry got disconnected Apr 23 20:37:45 amine43: https://pastebin.com/PAvP2aZB instructions to update the udev rule after reflashing Apr 23 20:38:23 with that update, you'll have /dev/remoteproc/pruss-core0/ and /dev/remoteproc/pruss-core1/ to use instead of /sys/class/remoteproc/whatever Apr 23 20:39:11 ok great thank you very mmuch for your help ! Apr 23 20:39:35 also I feel the urge to plug my py-uio library as alternative to the remoteproc stuff, which is a python library to inspect and control pru cores, load pru programs, and interact with them via shared memory and interrupts: https://github.com/mvduin/py-uio Apr 23 21:14:32 if it helps, I had worked on providing a similar library for the remoteproc framework to make it easier to control prus, load pru programs, use Rpmsg, etc: https://github.com/pratimugale/PRUSS-Bindings Apr 23 21:15:46 I'm trying to create a symlink called pru1 to the pru running the am335x-pru1-fw. The udev rule I created looks like as follows but doesnt appear to be working. Any suggestions: KERNEL=="remoteproc*", SUBSYSTEM=="remoteproc", DRIVER=="", ATTR{firmware}=="am335x-pru1-fw", ATTR{name}=="4a338000.pru", ACTION=="add", SYMLINK+="pru1" Apr 23 21:42:25 GenTooMan: Phew. I am back and in full-effect. Apr 23 21:43:30 I am searching for some items (again). I am going to get, how you say, some caps and some dc-dc converters to make sure I do not exume my bbb. Apr 23 21:44:32 GenTooMan: I have not deviated from the original schematic of the Half Duplex UART. Apr 23 21:45:11 I have basically copied that Half Duplex UART schematic into the circuit program called Micro-Cap. Apr 23 21:47:07 Now, I need to figure out other things. How can I make sure I do not "exume" my BBB into non-existence? I mean, I see the schematic but does it make sense to me? No. Where does TXD and RXD go to? It seems these pins are just floating or something? Apr 23 21:47:46 PRU_Tester: the latest bb-customizations package creates symlinks for the prus Apr 23 21:47:58 PRU_Tester: instructions to upgrade: https://pastebin.com/PAvP2aZB Apr 23 21:48:04 PRU_Tester: it creates the symlinks in /dev/remoteproc/ Apr 23 21:48:42 (those instructions assume you're running debian buster (10.x), as in the latest images. if you're using stretch (debian 9.x) then replace "buster" by "stretch" in the url) Apr 23 21:48:53 (if you're using option 2, that is) Apr 23 21:50:12 pratimugale[m]: remoteproc-pru doesn't actually support of the functionality of uio-pruss though, hence no wrapper can either Apr 23 21:51:13 (py-uio doesn't support rpmsg but that's because I don't care about it hence haven't found the motivation to implement it, although I did look into it and it wouldn't be hard to support) Apr 23 21:51:58 pratimugale[m]: ah I see you work around remoteproc's faults by using /dev/mem.... i.e. that's basically like using uio-pruss, except worse Apr 23 21:52:52 it requires root privileges and doesn't play well with the kernel's power management (hence resulting in bus errors if the pru core happens to be not running) Apr 23 21:53:17 pratimugale[m]: basically, anyone who ends up using /dev/mem is demonstrating that remoteproc sucks compared to uio-pruss ;) Apr 23 21:57:15 uio-pruss allows access similar to using /dev/mem except limited to just pruss and a chunk of shared memory in ddr3, without requiring root (the default udev rules puts uio devices in group "users"). it avoids bus errors (a peripheral/subsystem that uses uio will remain powered and clocked as long as the uio device is open or mmap()ed, and moreover uio_pruss keeps pruss enabled continuously). ... Apr 23 21:57:21 ...finally it allows interrupts to be delivered to userspace via a file descriptor Apr 23 21:58:38 and it still works the same on kernel 4.19 as it did on kernel 3.8, while remoteproc-pru has a different overlay for every major kernel version because they kept breaking compatibility :P Apr 23 22:17:30 GenTooMan: For this Half Duplex UART circuit, I have the 5v bench supply to use, a 10K resistor, the caps for the HC04, and jumper wires for the breadboard. If you are willing to procure some of your knowledge, I am ready to hook this pup up. Apr 23 22:19:03 To start, TXD on the schematic is just for labeling the transmission of the HC126 pins, right? Apr 23 22:19:33 So, one of the pins on HC126 is used as a RXD and the other for TXD? Apr 23 22:20:19 So. Whenever you are ready, I will keep checking back. Apr 23 22:20:51 zmatt Thanks. I'll check that out since I'm using custom version 10.3 buster image. Apr 23 22:21:19 PRU_Tester: you can also find the actual udev rule here: https://github.com/beagleboard/Latest-Images/issues/23#issuecomment-618263910 Apr 23 22:28:55 The only issue I have currently is the caps I have on hand, i.e. they are not listed as bypass caps. They are listed as Multilayer Ceramic. Would these work instead of the labeled bypass cap needed? Apr 23 22:30:27 zmatt: do you ever notice DTBs that are extremely not-up-to-spec ? Apr 23 22:30:41 am335x-boneblack.dtb is a particularly bad offender Apr 23 22:31:52 I haven't looked at the mainline dtbs in quite a while, though many dtbs definitely disagree with my sense of aesthetics. what do you mean by "not-up-to-spec" exactly? Apr 23 22:33:43 I just read that these MLCC are able to be used as bypass caps. Yea boy! Apr 23 22:34:22 zmatt: yes the remoteproc driver doesn't provide a method to access the PRU memory directly :(, using /dev/mem wasn't a primary goal. It would have been good to be able to integrate the PRU DMA project for bidirectional data transfers but I couldn't get it to start working; still uio has benefits compared to remoteproc :) Apr 23 22:35:37 pratimugale[m]: remoteproc just seems like a pointless step backwards for pru, although I understand its motivation and it has its uses for cores that are used in different ways (especially if they provide some auxiliary function to the kernel rather than being programmed by end users) Apr 23 22:36:09 but as long as you feel a need to use /dev/mem, that just means remoteproc is not ready to replace uio-pruss and you're better off sticking with uio Apr 23 22:36:37 (though it definitely could use a better userspace C/C++ library than the ancient libprussdrv) Apr 23 22:39:58 zmatt: dmas property is defined as a number of triplets, hsmmc's node has like 8 bytes Apr 23 22:40:56 dmas = <0x35 0x18 0x00 0x00 0x35 0x19 0x00 0x00>; Apr 23 22:40:58 kremlin: almost certainly you're just misinterpreting something, I feel quite confident to assume the dmas property for the mmc devices is correct, but I'll check the source code fo ryou Apr 23 22:41:03 those are cells, not bytes Apr 23 22:41:44 and you can't really parse a decompiled dtb like that with any ease, since parsing a property like dmas requires doing phandle lookups Apr 23 22:43:03 zmatt: agreed Apr 23 22:43:10 kremlin: yeah that's <&edma_xbar 24 0 0>, <&edma_xbar 25 0 0> which is fine since edma_xbar has #dma-cells=<3> Apr 23 22:43:42 kremlin: so the dtb isn't wrong, you're just confused about dtb :) Apr 23 22:43:43 OH Apr 23 22:43:44 man Apr 23 22:43:46 that makes so much sense Apr 23 22:44:04 i was wondering like..what is *with* this memory layout Apr 23 22:44:20 so those cells are just pointers to where the actual values lie Apr 23 22:44:39 if i wanted to properly parse it, i would just load the dtb in uboot and print it out there Apr 23 22:51:09 kremlin: https://pastebin.com/Q8BdZscT Apr 23 22:51:21 kremlin: pseudo-code for parsing the dmas property Apr 23 22:51:30 oh, ignore the int i = 0; Apr 23 22:51:45 gotcha Apr 23 22:51:51 there are tons of properties which work like this Apr 23 22:52:09 "phandles" Apr 23 23:04:45 Would the 1OE on the HC126 go to the BBB? Apr 23 23:05:52 1OE is the first output enable pin I will use. Apr 23 23:11:13 So, I handle the OE pins on the HC126 w/ a GPIO pin from the BBB? Apr 23 23:11:52 I think this is where the dc-dc converter comes in to play. Apr 23 23:13:00 kremlin: some more examples of the same patterns: https://pastebin.com/8NQQ5bam Apr 23 23:15:20 kremlin: dmas and clocks are the cleanest examples, and there are more that follow the exact same format (e.g. pinctrl and pwm). others can be a bit more quirky as you can see Apr 23 23:15:57 im poking around in uboot now Apr 23 23:16:08 what are you trying to do? Apr 23 23:16:29 just exploring Apr 23 23:16:45 i would like to see a printed fdt tree with all cells "resolved" Apr 23 23:17:16 I mean, that's difficult since much is lost when compiling a DT, you're better off reading the source code Apr 23 23:17:48 i mean, the actual values have to be in there somewhere, right? Apr 23 23:17:54 or else how does the thing boot ? Apr 23 23:18:14 yeah but in a way that's machine readable rather than human readable Apr 23 23:19:08 for example the node labels are lost (at least normally they are, although if you use a dtc with overlay support and compile with -@ then labels are remembered in a separate table to support resolving overlay references) Apr 23 23:19:51 as is all of the structure of properties, since in the DTB each property is just an array of bytes Apr 23 23:20:49 some of that structure can be recovered with some effort but it requires knowledge of the semantics of each individual property you want to parse (which may also be device dependent) Apr 23 23:20:50 it doesnt seem like u-boot is going to give me anything other than cell addresses Apr 23 23:21:02 what's a "cell address" ? Apr 23 23:21:10 what i posted earlier Apr 23 23:21:12 the dma lines Apr 23 23:21:20 note: "cell" is just a synonym for "32-bit integer" Apr 23 23:21:24 i'm not 100% on the terminology yet Apr 23 23:21:33 it's a pointer though, right ? Apr 23 23:21:46 what is? Apr 23 23:22:09 mmc@0 { Apr 23 23:22:11 compatible = "ti,omap4-hsmmc"; Apr 23 23:22:13 ti,dual-volt; Apr 23 23:22:15 ti,needs-special-reset; Apr 23 23:22:17 ti,needs-special-hs-handling; Apr 23 23:22:18 nodes are referenced via phandles, which are integers that are assigned to nodes via their "phandle" property" Apr 23 23:22:19 dmas = <0x35 0x18 0x00 0x00 0x35 0x19 0x00 0x00>; Apr 23 23:22:21 the dma property Apr 23 23:22:23 dmas * Apr 23 23:22:38 kremlin: you should really know better than pasting a block of text into IRC Apr 23 23:23:04 kremlin: the 0x35 is the phandle of the dma controller node Apr 23 23:23:09 oh, ok, so, i'd need to find whatever node has a property "phandle=0x32" to find out the first dma tripley Apr 23 23:23:39 35 * Apr 23 23:24:08 yep, when parsing DT one of the things you do is keep a table of each node by phandle... the phandles are sequentially numbered by the device tree compiler to every node (or at least every node that is referenced by phandle) Apr 23 23:24:27 *sequentially assigned Apr 23 23:25:03 how does the parser differentiate between properties whose values are phandles and properties whose values are literals ? Apr 23 23:25:47 it doesn't. dtc has no way of knowing whether the property value you write is structurally sane for that property Apr 23 23:26:07 see https://pastebin.com/XC8vB33d for an overview of DT source code, including the ways of writing property values in DT source Apr 23 23:26:13 dtc doesnt but dtb-parsing code does Apr 23 23:27:17 not generically. rather, the code that processes the "dmas" property knows the structure of the dmas property and parses it accordingly (as outlined in my pseudocode example) Apr 23 23:27:39 oh, so property names are special Apr 23 23:27:41 ok. Apr 23 23:27:52 there's no way to generically parse properties Apr 23 23:28:02 when you decompile a dtb using dtc it just makes some wild guesses Apr 23 23:28:42 it sounds like i need to get a hold of the original source for these Apr 23 23:28:48 so i can navigate the tree more sanely Apr 23 23:29:02 yes, you should almost never try to read a decompiled dtb, that's just pain Apr 23 23:29:44 i am sort of..getting back into this world Apr 23 23:29:47 for mainline linux you can find DT source code for ARM devices here: https://elixir.bootlin.com/linux/latest/source/arch/arm/boot/dts Apr 23 23:30:12 currently our ti,hsmmc driver for the bbb uses cpu/intr IO and not DMA Apr 23 23:30:22 im trying to get DMA working Apr 23 23:30:25 through EDMA Apr 23 23:31:01 so does openbsd not support any sort of DMA on any ARM devices yet? otherwise I'd assume there's already support for parsing dmas in place Apr 23 23:31:21 we support DMA on ARM Apr 23 23:31:27 there is an EDMA driver. nothing uses it Apr 23 23:31:43 lol, I'm sure it's been well-tested then Apr 23 23:32:05 anyway, so normally you wouldn't have to know what dma controller is being used Apr 23 23:32:29 GenTooMan: There has to be two HC126s on this circuit, right? How else would I direct what is happening inside of the chip w/out source? Apr 23 23:33:08 i probably *still* don't need to know but my approach is to figure out the nitty-gritty first Apr 23 23:33:09 rather, the driver asks for dma channels (typically by name) and generic support code will look up those channels from DT, find the associated dma controllers, ask their drivers to parse the rest of each dma channel declaration in DT and set things up for the requesting driver Apr 23 23:34:09 set_ how many circuits were in the diagram? 2 there are 4 circuits per IC Apr 23 23:34:55 Right...but can I just use Input on one to the Output of the other w/in the same IC? Apr 23 23:34:56 (or at least return some object representing the dma channel. the actual setup is probably done later of course) Apr 23 23:36:02 kremlin: https://elixir.bootlin.com/linux/v5.6.7/source/drivers/mmc/host/omap_hsmmc.c#L1938 for example, this shows the two dma channels being requested in the linux omap_hsmmc driver Apr 23 23:36:17 So...HC126 I1 to O2 && HC126 I2 to O1? Like so? Apr 23 23:36:23 kremlin: the "tx" and "rx" reference the names specified in the dma-names property Apr 23 23:36:41 aha Apr 23 23:36:43 ok Apr 23 23:36:53 so 'tx' and 'rx' specify which DMA channels are needed uniquely Apr 23 23:37:44 yep. dma_request_chan will loop over the names in the dma-names property to find the exact match, and that array index is then the index into the dmas array which describes the channel Apr 23 23:38:13 okay, that makes things muich clearer Apr 23 23:38:51 GenTooMan: I tied everthing to ground almost but for OE1, 1A, and 1Y, and Vcc (of course) on the HC04 so far. Apr 23 23:39:13 So, what should I do about the OE pin for the HC04? Apr 23 23:39:13 oh apparently it actually allows multiple dma channels with the same name, and it'll pick one pseudo-randomly for load-balancing :D Apr 23 23:39:16 I didn't know that Apr 23 23:39:35 kremlin: https://elixir.bootlin.com/linux/v5.6.7/source/drivers/dma/of-dma.c#L236 Apr 23 23:40:14 Just for experience here, I have used OE pins on chips before but it from GPIOs onboard the BBB. Apr 23 23:40:30 the first thing i'd need to do then is set that channels interupt handler to a new function in our mmc driver -- our edma driver exposes a function for that, it takes a channel, a function pointer for the handler, and misc. data ptr Apr 23 23:41:10 kremlin: openbsd has no generic dma API? Apr 23 23:41:20 it does Apr 23 23:41:26 this is where i'm not exactly sure of things Apr 23 23:41:37 we have edma(4) which is a machine-dependent driver for the am335x EDMA Apr 23 23:41:43 okay, since other TI SoCs use a different dma controller than EDMA Apr 23 23:41:54 (with the same omap-hsmmc driver) Apr 23 23:42:04 we also have http://man.openbsd.org/man9/bus_dma.9 Apr 23 23:42:26 the word "edma" does not occur in the linux omap_hsmmc driver, it doesn't care what dma controller is used Apr 23 23:42:49 kremlin: that's just dma memory mapping it seems Apr 23 23:43:05 not an actual dma API Apr 23 23:43:12 i am pretty sure i use edma(4) to plug into the interupt and the machine-independent DMA functions to like, let the virt. mem. subsystem know what im touching Apr 23 23:43:46 bear with me Apr 23 23:43:52 this is somewhat new to me Apr 23 23:44:09 okay but that hardcodes a dependency on the edma driver Apr 23 23:44:29 but what dma controller should be used is specified in DT, it shouldn't be hardcoded in the driver Apr 23 23:45:09 wait a minute Apr 23 23:45:15 So, I have to make sure OE is high for my I/O to work on this chip, i.e. the HC126. I guess from a GPIO. Apr 23 23:45:36 when i say edma(4) i am referring specifically to our MD driver that supports the functionality specified in chapter 11 of the TRM Apr 23 23:45:54 https://github.com/openbsd/src/blob/master/sys/arch/armv7/omap/edma.c Apr 23 23:46:00 https://github.com/openbsd/src/blob/master/sys/arch/armv7/omap/edmavar.h Apr 23 23:46:03 that ^^ Apr 23 23:46:56 I understand, that would be the driver for the edma device (compatible = "ti,edma3-tpcc") Apr 23 23:47:46 you are saying that there is the possiblity that some other ti,hsmmc node could ask for a different DMA controller ? Apr 23 23:47:55 I got it now. I just use a pull-up resistor to GND for my OE pin used on the HC126. So, I guess I use two pull-up resistors for the two OE pins that will be used and tie them into GND. Apr 23 23:48:33 Then, my inputs will be tied to each other and the outputs will be tied to each other. Apr 23 23:49:29 kremlin: yes, technically even on the am335x since some devices ask the edma_xbar controller, but that's basically just a thin wrapper that sets up a crossbar mapping but otherwise just delegates the work Apr 23 23:49:40 kremlin: on the am57xx a completely different dma controller is used Apr 23 23:51:13 i don't think we are concerned with generalizing our driver to this degree Apr 23 23:51:39 we do not have linux levels of programmer power Apr 23 23:51:43 oh actually I think it might use the integrated dma there? not quite sure Apr 23 23:51:52 GenTooMan: Now, how can I figure out what type of pull-up resistor to use? I mean, 1k, 10K, etc? What way is there to figure it out? Apr 23 23:52:23 kremlin: I mean, not doing this generically means ignoring DT and using some hardcoded driver-specific SoC-specific hack Apr 23 23:52:36 so... you do you I guess Apr 23 23:53:06 So, I need to account for 70 mA. Apr 23 23:53:11 we do not have a generic low level DMA driver Apr 23 23:53:19 once you hope you support more than one TI SoC you'll end up having to do it generically anyway probably (or add more hacks upon hacks) Apr 23 23:53:26 *hope to support Apr 23 23:53:38 i might be confused. Apr 23 23:53:41 https://mirror.esc7.net/pub/OpenBSD/snapshots/armv7/ Apr 23 23:53:48 do you see how we have miniroot-*.fs ? Apr 23 23:54:12 (this is our distrib tree btw, the fs files are install images) Apr 23 23:54:34 we don't have one generic kernel we ship that will suit all devices Apr 23 23:54:35 not getting any response from that webserver ("Connecting...") Apr 23 23:55:00 http://mirror.planetunix.net/pub/OpenBSD/snapshots/armv7/ Apr 23 23:55:02 try that Apr 23 23:55:03 I understand, and I wasn't saying you should Apr 23 23:55:32 but you'll still want a generic DMA api, otherwise you'd have to implement support for multiple DMA controllers in every peripheral where you want to use dma Apr 23 23:55:59 and without generic DMA you'd also have to hardcode into your kernel information that would normally be obtained from DT Apr 23 23:56:16 (from the "dmas" property) Apr 23 23:56:31 you are saying, that in the future, there could be another ti,hsmmc that wants not-edma, but because our driver will match that, it will try to use edma, to no avail Apr 23 23:56:49 right ? Apr 23 23:58:03 kremlin: https://elixir.bootlin.com/linux/v5.6.6/source/arch/arm/boot/dts/omap3.dtsi#L465 Apr 23 23:58:17 voila, omap3-hsmmc driver instantiated with dmas pointing to &sdma Apr 23 23:58:23 sdma... Apr 23 23:58:27 that is not edma.. Apr 23 23:58:29 which is a DMA controller that doesn't remotely resemble EDMA Apr 24 00:01:01 https://elixir.bootlin.com/linux/v5.6.6/source/arch/arm/boot/dts/am33xx-l4.dtsi#L1330 Apr 24 00:01:10 and here it specifies EDMA Apr 24 00:01:14 which i did not see earlier Apr 24 00:01:18 because i was looking at the dtc Apr 24 00:02:16 ugh all the sysc stuff does make the DT messier Apr 24 00:04:37 on am572x it's even more fun: its dma requests go to a dma crossbar and can be routed either to the SDMA instance or one of the three EDMA instances. alternatively, two of the MMC instances have integrated DMA support Apr 24 00:06:02 so for example, here for uarts you see it using SDMA via crossbar: https://elixir.bootlin.com/linux/v4.19.118/source/arch/arm/boot/dts/dra7.dtsi#L622 Apr 24 00:06:04 So, now I am venturing into Current Sourcing for this driver. Apr 24 00:06:30 5v - ______ / 0.035A? Apr 24 00:06:57 (the crossbar driver will allocate an sdma channel, setup the crossbar mapping for the indicated dma request input, and delegate the rest of the work to the sdma driver) Apr 24 00:07:43 I need to tie the pull-up resistor to GND but first I need to figure out what value is in the ______ location of my formula. Apr 24 00:07:47 How would I go about this idea? Apr 24 00:08:37 kremlin: and actually the same crossbar driver is used for sdma and edma, it works generically for either: https://elixir.bootlin.com/linux/v4.19.118/source/arch/arm/boot/dts/dra7.dtsi#L221 Apr 24 00:09:53 weird that it says one has 204 requests and the other has 205, I'm pretty sure the inputs are exactly the same for both Apr 24 00:10:07 w/out testing and w/ reading over the HC126 (lack of info) datasheet, I have come across the idea of finding the current-sourcing capability of the driver. I figured it was easy. Oops. Apr 24 00:14:10 So, out of the circuit device/driver comes an amount of something when it is applied 5v. I saw on the datasheet that there is +/- 6mA at 5v and 1uA max input current. Apr 24 00:14:19 kremlin: you may just want to take it one step at a time though.. you'll want to have experience with dma in *some* form as well as have a working test-case before tackling the problem of introducing generic dma handling (if openbsd is indeed currently lacking that) Apr 24 00:14:34 good lord Apr 24 00:14:51 this stuff gets ugly quick Apr 24 00:15:04 but i am starting to see how it comes together Apr 24 00:15:06 I wouldn't call it ugly Apr 24 00:15:15 but it's perhaps not as simple as you'd hope Apr 24 00:15:36 for now we will hardcode edma but it doesnt seem too ridiculous to have a simple system that matches the compat line of the dma node to whatever the mmc node dma prop wants Apr 24 00:15:56 ehhh Apr 24 00:16:29 I have no idea what you mean by that, but I suspect it's not right Apr 24 00:16:58 i mean, to have a generic DMA interface that picks the right dma controller generically Apr 24 00:17:07 100ohm it is! Apr 24 00:17:07 that's done by phandle lookup Apr 24 00:17:17 as part of parsing the dmas property Apr 24 00:17:49 o Apr 24 00:18:47 you'll need to at least look up the DT node to even be able to parse the dmas property at all (since you need its #dma-cells to know how many words to skip to get to the next dma channel descriptor) Apr 24 00:19:53 and to request the dma channel you'd then ask that dma controller (as in, the one corresponding to the DT node found by phandle lookup) to parse the rest of the dma descriptor, since only it knows its meaning Apr 24 00:21:45 defining a generic dma api doesn't really sound like a hard thing to do, it's just an abstraction, but should you intend to tackle that at some point you'll definitely first want to have some experience with dma and look around at other examples (or save some work by peeking the linux' dmaengine api) to know what sort of things may be expected from it Apr 24 00:22:11 gotcha Apr 24 00:22:26 not that the linux dmaengine api is perfect, but still :P Apr 24 00:25:06 (should you want feedback on that at any point, I'm here) Apr 24 00:26:42 zmatt, thank you truly for your help Apr 24 00:26:46 it is invaluable as always Apr 24 00:30:13 kremlin: also, should you run into any interesting issues with edma, my notes in https://liktaanjeneus.nl/edma3.h.html may perhaps be of use. apologies for not using the same register terminology as the TRM, I preferred to use sensible names instead of ones that look like a cat walked on my keyboard Apr 24 00:30:32 awesome, ty Apr 24 00:31:37 should you read it, start by clicking edma3-tc.h at the top Apr 24 00:33:11 (also apologies for the "let", that's just my eccentric style of C++ with #define let auto Apr 24 00:33:15 ) Apr 24 00:34:50 zmatt, I have a question. I'm starting to learn Python3. What ends a while or for loop? Apr 24 00:36:09 you mean how to break out of one prematurely? Apr 24 00:36:36 your question is a bit ambiguous Apr 24 00:37:10 Unlike C there seems to be no 'end' of a function like for x in ..... done Apr 24 00:37:27 try except? Apr 24 00:37:41 python uses significant indentation: the body of a block-statement needs to be indented related to that statement Apr 24 00:37:57 (or it needs to be a single line and placed after the :) Apr 24 00:38:11 python seem to be sensative to where on a line a for or while starts Apr 24 00:39:15 I can upload a sample I've been working? Apr 24 00:40:08 KenUnix: https://pastebin.com/AxXK1Lnz Apr 24 00:40:50 Here is my sample https://paste.debian.net/1142685/ Apr 24 00:42:27 The script run but the first 5 loops does nothing Apr 24 00:42:45 KenUnix: https://paste.debian.net/1142686/ Apr 24 00:43:05 correct, that's what you wrote Apr 24 00:43:31 you're also doing setup for the relays 4 times Apr 24 00:43:55 But why do the first 5 loops do not light the led's or relays? Only the last koop Apr 24 00:43:58 Does Adafruit-BBIO still work on the new images? Apr 24 00:44:32 KenUnix: you're executing the for-loops that change the gpios *after* the while-loop, not *in* the while loop Apr 24 00:44:44 See my comments in script. Yes use git then make then sudo make install Apr 24 00:44:45 see the link I just gave Apr 24 00:44:57 set_ wasn't a nominal value already given for the pull up? 10k is merely to prevent the output from floating (bad) Apr 24 00:45:13 KenUnix: is it not installable via pip3 ? Apr 24 00:45:46 GenTooMan: You are alive again! Good. Apr 24 00:46:09 actually never mind Apr 24 00:46:11 it's installed by default Apr 24 00:46:17 so you don't need to install it at all Apr 24 00:46:40 Right but that is from the power source and not for the OE pin that needs to have a pull-up resistor connecting to GND. Apr 24 00:46:58 Well python was initnally complaind adafruit was not there now its happy Apr 24 00:47:30 https://pastebin.com/z7bcAruX Apr 24 00:47:54 it's there on my bbb, and I just reflashed it today with the latest image Apr 24 00:47:57 I came to this conclusion: 5v - 2v / 0.035A = 100ohm? Apr 24 00:48:16 set_: parentheses Apr 24 00:48:24 Sorry. Apr 24 00:48:48 THe HC126 needs a pull-up resistor attached to GND from the OE pin in use. Apr 24 00:48:50 KenUnix: if you want the for-loops to be inside the while-loop, indent them appropriately Apr 24 00:49:09 zmatt, OK, How do I extend the while to cover both for loops? Apr 24 00:49:20 So, to what @zmatt is saying, (5v - 2v) / 0.035A = 100 ohm. Apr 24 00:49:21 likewise if you want the relay-setup to be after the led-setup loop (rather than pointlessly inside it), unindent it Apr 24 00:49:36 Indent. This is worse then Cobol Apr 24 00:49:54 KenUnix: why? sanely written code in almost any language will already be properly indented anyway Apr 24 00:50:17 What's considered a proper indentation Apr 24 00:50:47 GenTooMan: I just am not sure just yet. How can I connect HC126 to HC04 and back? Apr 24 00:51:30 KenUnix: https://pastebin.com/ngu8hhR2 in C Apr 24 00:52:30 I have the OE pin on the HC126 tied to a pull-up resistor and then to GND on the breadboard. Apr 24 00:52:36 KenUnix: https://pastebin.com/xWXWEuCm likewise in python Apr 24 00:53:28 THen, the HC04 has Vcc tied to a MLCCap for the bypass cap it needed to Vdd on the breadboard. Apr 24 00:53:51 the main difference is that doing it wrong in C is just ugly and hard to read, while doing in wrong in python will also be semantically wrong Apr 24 00:54:04 or said differently, python forces syntax and semantics to agree with each other :P Apr 24 00:54:11 Now, the chips, like you pointed out GenTooMan, need to have no floating pins. I got this idea down pat. Apr 24 00:54:11 which is not a bad thing Apr 24 00:54:35 I am tying everything to GND. Apr 24 00:54:57 zmatt, When I indent and run now I get : IndentationError: unindent does not match any outer indentation level Apr 24 00:55:44 KenUnix: then you probably have weird amounts of indenting Apr 24 00:56:12 So the use of { and } is no good? Apr 24 00:56:41 python has no {} Apr 24 00:57:07 here's an example of what you might have done wrong to get that error: https://pastebin.com/aMtR1YdF Apr 24 00:58:59 This is how it looks now https://paste.debian.net/1142689/ Apr 24 01:00:15 yep, exactly that problem Apr 24 01:01:32 (also you still need to unindent the setup lines for the relays, it makes no sense to do them in the for i in range(LEDs) loop) Apr 24 01:01:56 I have never seen a languare that used tabs that way Apr 24 01:02:43 your while-loop initially uses 8-space indent and then you switch to 4-space indent. use one of those consistently, not a mix Apr 24 01:03:51 yeah python is somewhat unusual in this, though it's well-motivated and even though I used to hate it I've actually come around and now think it's a good idea (though I still don't like python overall) Apr 24 01:09:24 This version works as desired https://paste.debian.net/1142690/ Apr 24 01:10:23 yep. still uses a mix of 8-space and 4-space indent which I'd disagree with on aesthetic grounds, but this time it is indeed valid Apr 24 01:11:05 Supposedly, python always wants four spaces. Apr 24 01:11:17 no, python doesn't care about the number of spaces Apr 24 01:11:26 I mean for indentation. Apr 24 01:11:26 at long as you're consistent within each block Apr 24 01:11:30 yes Apr 24 01:11:30 Oh. Apr 24 01:11:35 *as long as Apr 24 01:11:36 Where are 4 and 8. I moved setup apart leds from relay ports Apr 24 01:12:10 KenUnix: your top-level blocks use 8 spaces for their body, while the two inner for-loops use 4 additional spaces for their body Apr 24 01:13:37 GenTooMan: All of my HC126 pins are taken up now, e.g. Vcc, GND, and the pins not used are tied to GND. Apr 24 01:13:40 so the indent for each individual block is consistent (which is all that python requires) but the different blocks use different amounts of indent (which python doesn't care about, but it's not tidy) Apr 24 01:19:32 Now, all the HC04 and HC126 pins are tied to GND. So, I just need to configure which pins on the HC126 will be used. If I choose... Apr 24 01:19:33 ... Apr 24 01:19:59 OE1 and OE2, this means I need to fix up the OE2 also w/ a pull-up resistor. Apr 24 01:20:11 Right now, I am just set up w/ OE1. Apr 24 01:20:38 So, from OE1, Y and A are my I/O. Apr 24 01:21:07 Oh. I see now. I can referece LED's with GPIO.output("USR%d" % i ,GPIO.HIGH) but not so for the relays? Apr 24 01:22:24 What? I thought both worked together. Apr 24 01:22:41 KenUnix: just use an array Apr 24 01:22:51 So, if GPIO P9.41 was High, the LED and Relay was on. Apr 24 01:22:59 the adafruit library has some lookup table for the leds, while it obviously doesn't know anything about the relay cape Apr 24 01:24:11 zmatt, OK. Can you give me an example? Apr 24 01:25:09 set_ Yes relay & it's led on. The other was the user led. Apr 24 01:25:25 Oh. Apr 24 01:25:26 Okay. Apr 24 01:26:37 KenUnix: sure Apr 24 01:28:46 set_, I think I will forgo the maintainer job for bwbasic from Debian. Guy who had it prior e-mail'd with me and the reason hi gave it up was because he left Debain. Am I biting off more then I can chew?? Apr 24 01:29:23 KenUnix: https://paste.debian.net/1142693/ something like this? Apr 24 01:30:05 line 18 is just shorthand for leds = [ "USR0", "USR1", "USR2", "USR3" ] Apr 24 01:30:21 except I'm not sure it's actually shorter, but oh well :P Apr 24 01:30:24 Who know? Apr 24 01:30:27 "2 or more, use a for!" Apr 24 01:30:45 set_ so you have 2 circuits with the HC126 and an inverter driving one of the HC126 output enable? almost exactly like the diagram given? Apr 24 01:30:56 KenUnix: I do not know. I know nothing about how things change constantly w/ maintaining. Apr 24 01:31:07 Getting odd behavior booting up the BBB with the cape attached Apr 24 01:31:21 wont turn on Apr 24 01:31:21 "the cape" Apr 24 01:31:27 lcd cape Apr 24 01:31:33 what lcd cape? Apr 24 01:32:20 GenTooMan: I am not sure yet. I think I need two circuits w/ the HC126 but I only have the one HC126 w/out any outer circuitry. Apr 24 01:32:24 new haven display one second for the model number Apr 24 01:32:26 also define "wont turn on" .. you mean not even the power led turns on? Apr 24 01:32:44 NHD-7.0CTP-CAPE Apr 24 01:33:04 so if I just plug in the BBB and the 2A adapter to the 5V jack Apr 24 01:33:16 screen will flash and no lights on the BBB Apr 24 01:33:21 so I remove the BBB Apr 24 01:33:27 plug in the jack and it boots Apr 24 01:33:31 no lights on the bbb, not even the power led? Apr 24 01:33:48 set_ Vince told me it would only keep running what's there and put out the major fires. Apr 24 01:33:50 GenTooMan: Let me get a photo of what is going on. Apr 24 01:34:21 KenUnix: Okay but now, but now, I am neck deep in wiring and chips. brb Apr 24 01:35:57 MattB0ne: I'm assuming the power led on the bbb also flashes briefly, just like the backlight of the lcd? Apr 24 01:36:10 set_ In other words put up what I done to bring it from version 2.2 to 3.2a. The only missing link is the Makefile. Never made one. It could be somplie and not demanding. Just make and sudo make insttall. Apr 24 01:36:15 possibly was not looking at it Apr 24 01:36:25 sort of obscured by the cape Apr 24 01:36:38 so when it is doing that cylcing i unplug the usb Apr 24 01:36:52 what cycling? Apr 24 01:36:58 then power through the 5V and it turns on Apr 24 01:37:21 when I just have power coming in through the usb with the cape attached it wont turn on Apr 24 01:37:27 its like a car trying to turn over Apr 24 01:37:29 zmatt, your 'py' is called zmattsrelay.py Apr 24 01:37:30 screen flashes Apr 24 01:37:39 power light flashes Apr 24 01:37:40 mastermind_: sounds like your usb can't provide enough power for the backlight Apr 24 01:37:44 but never boots Apr 24 01:37:47 right Apr 24 01:37:53 so I unplug that Apr 24 01:37:54 though if both usb and 5v adapter are connected it should use the 5v adapter Apr 24 01:38:02 it doesnt Apr 24 01:38:05 unless the usb supply has a higher voltage Apr 24 01:38:07 it seems stuck on the usb Apr 24 01:38:14 in terms of priority Apr 24 01:38:19 No, remember I have the same isssue Apr 24 01:38:21 priority is determined by voltage Apr 24 01:38:29 but if I unplug the usb Apr 24 01:38:30 some usb supplies have an out-of-spec high voltage Apr 24 01:38:42 and put the 5V in it will boot Apr 24 01:38:49 set_ you could draw up a schematic in KiCAD like I would but that might take a while. Apr 24 01:38:52 (to try to compensate for voltage drop in crappy cables I guess) Apr 24 01:38:52 but what is weird is I have to go through that whole process Apr 24 01:39:16 zmatt - As you told me chabge to Ethernet no USB to PC Apr 24 01:39:31 KenUnix: I mean, usb and 5v adapter at the same time works fine for me Apr 24 01:39:36 zmatt: hey, you ever have any luck debugging these things with a buspirate or xds100 or similar ? Apr 24 01:39:47 kremlin: xds100v2, sure Apr 24 01:39:51 weird behavior should I be worried Apr 24 01:39:54 seems fine now though Apr 24 01:40:02 kremlin: never done kernel debugging though, just baremetal stuff and SoC exploration Apr 24 01:40:03 Yes they do but either one will keep the BBB up. Apr 24 01:40:14 am i out $100 if i want to get one ?? Apr 24 01:40:14 KenUnix: not for me Apr 24 01:40:24 whoops, single question mark inteded Apr 24 01:40:54 We went round and round about this before Apr 24 01:41:36 KenUnix: yeah, my conclusion was that it was probably some tps65217 bug, though I don't know what the specific conditions are that trigger the problem in your situation but not mine Apr 24 01:41:55 Using Ethernet and external power work ok Apr 24 01:42:05 KenUnix: anyway, your issue was about it refusing to remain shut down, that's not what the current topic is about Apr 24 01:42:49 What's his issue? Apr 24 01:42:58 MattB0ne: it may be interesting to check what voltage the "5V" is on your usb vs your 5V adapter Apr 24 01:43:21 ok Apr 24 01:43:41 MattB0ne: according to the cape datasheet the backlight draws 180 mA, which is certainly a significant amount of current though not excessive Apr 24 01:43:58 oh snap, the xds100v3 design files include "scrambled" FPGA HDL Apr 24 01:44:03 i might not have to spend any money Apr 24 01:44:08 oh wait it does have a control signal, the schematic is just confusingly Apr 24 01:44:20 kremlin: I have no experience with the v3 myself, it's a very different design Apr 24 01:45:18 kremlin: of the three jtag debuggers I've used (xds100v2, flyswatter2, st/link-v2), the xds100v2 is definitely by far the best Apr 24 01:45:52 it's basically just an ft2232h + cpld that's mostly used as level shifter, but that cpld makes it behave very well electrically Apr 24 01:46:23 while trying to hotplug the st/link-v2 invariably causes the reset line to glitch resulting in a target reset Apr 24 01:48:09 the xds100v2's i/o is high-impedance while either the xds100v2 or the target is unpowered, and they also go immediately high-z if the target loses power (even if momentarily) and they remain like that until software acknowledges the power loss event Apr 24 01:49:42 v2 has cpld files. that may work Apr 24 01:49:51 may work for what? Apr 24 01:50:26 the important part of the cpld is its electrical characterisics. its logical functionality in the xds100v2 is negligible Apr 24 01:50:48 im trying to program a FPGA or CPLD i have laying around isntead of shelling out for one Apr 24 01:52:00 the main purpose of the cpld is level-shifting between its two I/O banks (one connected to the ft2232h, the other connected to the target and powered by a supply that is generated from the usb 5v by using the target supply voltage as reference) Apr 24 01:54:12 GenTooMan: If you are around now or later, please read my nice photo! Please hold. I will get it. Apr 24 01:54:20 if you don't care about behaving well electrically you could use openocd's gpio-bitbang driver on a beaglebone or rpi :P Apr 24 01:58:04 https://drive.google.com/file/d/1DAtJuddEvQoGaT3GpJy0ERSPu2UP9ew-/view?usp=sharing is the link to the nice photo. Sorry for the oddities but I am not done and it needs work plus I have not way to determine how to connect the HC126 to itself and then connect the HC04 to the HC126. Apr 24 01:59:07 The Floating pins are my HC04 1A and 1Y pins b/c I have not used them just yet. Apr 24 02:00:22 Nice drawing Apr 24 02:02:11 Heres a drawing I did back in 1972 https://www.flickr.com/photos/9479603@N02/1814547305/in/album-72157602826941455/ Apr 24 02:03:45 No more but this one https://www.flickr.com/photos/9479603@N02/1814547427/in/album-72157602826941455/ Apr 24 02:04:18 Nice. Apr 24 02:04:35 MultiColor! I am sure it is better than just my plain, old black ink. Apr 24 02:05:01 This is what I hack in 1972 Apr 24 02:06:07 Office works! Apr 24 02:06:08 Wonder what 'A' board is ? Apr 24 02:06:35 A board? Sure, what? Apr 24 02:07:09 I humungous piece of perfboard and some analog circuits? Apr 24 02:07:16 The was when they had cord switchboards with operators. No 'office' in 1972 Apr 24 02:07:24 Nice. Apr 24 02:07:39 I saw the movie. I never once came up on switchboards in my time. Apr 24 02:08:00 They are all gone now Apr 24 02:08:10 Oh. Apr 24 02:08:26 Replaced by TSPS Apr 24 02:09:11 https://www.flickr.com/photos/9479603@N02/3846813702/in/album-72157602826943085/ Apr 24 02:09:41 GenTooMan: Hey, um...would 1A and 1Y on the HC04 go to an Input and Output on the HC126? Apr 24 02:10:02 KenUnix: Before my time, too. Apr 24 02:10:15 This is cord boards https://www.flickr.com/photos/9479603@N02/1815395258/in/album-72157602826943085/ Apr 24 02:10:58 That is what I remember from the movies. Apr 24 02:11:41 Yea, got to work on them. OK enough back to BBB Apr 24 02:11:46 BBB!@ Apr 24 02:13:03 Just for reference, here is the link again ---> https://drive.google.com/file/d/1DAtJuddEvQoGaT3GpJy0ERSPu2UP9ew-/view?usp=sharing Apr 24 02:14:12 Please remember the bottom chip is the HC04 and the chip above that one is the HC126. Apr 24 02:16:51 Now...I can put the OE1 and OE2 on the HC126 in route to GND by way of resistor (pull-up). So, this will make it so I can use 1A, 1Y, 2A, and 2Y. Apr 24 02:16:53 ... Apr 24 02:18:15 The issue is that, now, I do not know if I need to tie in (OE1 to OE2) and (1A to 2A) and (1Y to 2Y). Apr 24 02:18:38 B/c, I have not any way to test the inner circuitry of this chip. Apr 24 02:38:30 Or...blah. Apr 24 02:38:33 Dang it. Apr 24 02:42:29 My BeagleBone picture place is almost ready at: https://www.flickr.com/photos/9479603@N02/albums/72157714017739502/with/49687032797/ Apr 24 02:45:52 Alright. I have two AA batteries, a battery holder, and a gnarly idea! Apr 24 02:46:12 Ever been here : https://linuxpropaganda.wordpress.com/category/beaglebone-black/ Apr 24 02:46:33 OhOh idea.. Apr 24 02:47:04 I done been dear now. Apr 24 02:48:08 ok now I cannot boot up the beagle with the cape Apr 24 02:48:13 arggggg Apr 24 02:48:17 dang! Apr 24 02:48:22 my volt meter is in the office Apr 24 02:48:29 works fine without it Apr 24 02:48:34 buuuutttt Apr 24 02:48:41 i got this nice lcd cape Apr 24 02:48:44 non functional Apr 24 02:49:23 Do you have a powered USB hub w/ keyboard and a mouse? Apr 24 02:49:24 i guess I need to check my adapter Apr 24 02:49:45 what do you mean ? I just have the lcd cape Apr 24 02:50:06 Right...but! How would you sign in once the cape works? Apr 24 02:50:30 W/ thought. NO. You will need the keyboard and mouse. Apr 24 02:50:40 no i dont Apr 24 02:50:43 Oh? Apr 24 02:50:45 Okay. Apr 24 02:50:48 i can just ssh in Apr 24 02:50:55 To the Cape? Apr 24 02:50:59 Nice! Apr 24 02:51:04 to the beagle with the cape Apr 24 02:51:09 was working now it is not Apr 24 02:51:29 Oh. I am most likely barking up the wrong tree but... Apr 24 02:51:32 what does eprom due Apr 24 02:51:36 I have a LCD Cape too. Apr 24 02:51:41 ok Apr 24 02:51:53 do* Apr 24 02:52:05 I need a powered usb hub to control the keyboard and mouse for when I do get to sign in on my cape. Apr 24 02:52:46 It is touch screen too but I still need to sign in b/c the mfg. did not put any qwerty on the sign in screen. Apr 24 02:58:02 i am postive not having a powered usb port is the issue Apr 24 02:58:10 that is not how the cape connects Apr 24 02:59:34 Okay. How are you going to sign in to the prompt when it pops up on your cape? Apr 24 02:59:45 Is it touch screen? **** ENDING LOGGING AT Fri Apr 24 02:59:57 2020