**** BEGIN LOGGING AT Fri Feb 07 02:59:57 2020 Feb 07 03:00:33 at least you know how to read your scope. Mine is hibernation. Feb 07 03:07:27 GenTooMan: Have you ever transferred data from one chip to alter it in a new chip? Feb 07 03:08:56 an obtuse question, I've programmed Mcu's copied the image reduced the image and programmed a different IC (even disassembled the code) with it, if that's what you are asking. Feb 07 03:09:47 I think that is what I was getting at there w/ my little question. Feb 07 03:12:18 So, I have to open both TRMs, transfer the data w/ the original source, and pray for rain! Feb 07 03:12:58 Wish me luck...please. Feb 07 03:13:00 it's possible as long as you can read the JTAG port and the SW you have to use for programming it supports reading it. Most arm processors have the JTAG port disabled in commercial products so people can't mess things up. Feb 07 03:14:29 Oh. Feb 07 03:14:54 That makes sense. I found an old server and it had an arm chip on it. I wanted it so badly but I had to destroy it. Feb 07 03:15:06 Damn bosses. Feb 07 03:15:31 you disarmed it? :D Feb 07 03:15:52 I never knew what people meant by "beefer" and yes, I disarmed the arm against my better judgment. Feb 07 03:16:06 Orders from headquarters. Feb 07 03:18:15 Well things aren't what they seem. For example the reason for doing that might not be obvious. Legal responsibilities legal obligations, due diligence, GOK (God Only Knows). Feb 07 03:19:46 Oh. Yea. People were maybe supporting bad habits or financial crud. Feb 07 03:20:09 Who knows is right. I would have liked to erase it and start from scratch w/ it. Feb 07 03:26:42 learning from history is a good idea.. but don't take other peoples word what it means. People who talk about rewriting history, obviously don't care about reality. Feb 07 03:28:20 Okay but I warned you? Feb 07 03:31:31 I gave the person credit in the script for producing it. He just did not supply the two or three files I have in my possession that need altering. Feb 07 03:35:27 well as long as you fit the license agreement supplied by each author you are OK. Otherwise you may need to rewrite some of it. Feb 07 03:35:43 I also just realized that this script is for the am4376. Sheesh. I am goofing up now. Feb 07 03:36:17 Yep. I noticed that the script this person gave had no license but I gave him credit nevertheless. Feb 07 03:36:20 That's on the panda board. I have a few of those. Kind of cool, I should put a kernel in one and boot up. Feb 07 03:36:32 Hmm! Feb 07 03:42:11 This is going to be an extremely long project. Aw! Feb 07 03:56:08 I will need three total TRMs for this production and it is not a tonight-thing. Off to goof around! Feb 07 03:57:15 You get what you invest. Goofy things for goofing around. Feb 07 04:36:11 Yea boy! Feb 07 10:13:11 Does U-Boot overlays uEnv.txt work on debian8 console version ? Feb 07 10:14:51 (4.4.23-ti-r51) Feb 07 11:41:29 fred__tv_: u-boot overlays only depends on u-boot, not on distro version or kernel version Feb 07 11:41:51 but why are you using an obsolete debian release and obsolete kernel? Feb 07 11:46:04 like, I can sort of understand people who are sticking with their working wheezy/3.8-era system because so much has changed since then (though I personally really wouldn't want to be the one having to maintain/support that), but I don't think all that much has changed between jessie/4.4 and stretch/4.14 ? Feb 07 11:46:38 or buster/4.14 even (that's what I upgraded our devices to and I'm quite happy with it) Feb 07 14:29:30 Hi, basically because there is an already working system with jessie, and fear to break something with a distro-upgrade or kernel upgrade Feb 07 14:30:02 Whe you haven't skill in fixing something broken....that's it ! Feb 07 14:33:33 Anyway it would be nice to use overlay-utils with jessie, is it possible without pain ? Feb 07 14:34:23 I don't see how it would matter whether you're using jessie Feb 07 14:35:51 and obviously you'd perform the upgrade on a test/development device after making a backup, and you wouldn't deploy the new version until you've resolved any problems you may encounter and you're confident everything works Feb 07 14:37:22 I personally try to keep a dev system reasonably uptodate Feb 07 14:38:46 (rather than delaying until things get really obnoxiously old or you're forced to upgrade to fix a bug or because you need a new feature, since the longer one delays updates, the more painful it'll probably be) Feb 07 14:39:36 I still have some white running ubuntu 12.04 :-)))) Feb 07 14:41:48 What's your suggestion for the easiest system update for dummies ? Feb 07 14:43:55 I mean, fixing shit if it breaks on upgrade is just a skill you learn by doing it I think. although tbh it doesn't happen very often, not even on my laptop where I run debian unstable Feb 07 14:44:23 for deploying updates to our production devices we use custom tools Feb 07 14:45:32 for the full system update we used a procedure that basically replaces the entire filesystem atomically, preserving only device identity (machine id, hostname, ssh keys, etc) and user data Feb 07 14:47:38 (doing it atomically requires having both old and new system at the same time temporarily during the update, which we could do since we use much less than half the space on eMMC) Feb 07 14:55:14 I mean, in my poor knowledge, is an apt-get dist-upgrade enough ? Feb 07 14:56:38 by itself that just updates packages to the latest version of your current debian release. it will not cause you to switch to a newer release, nor will it (on the BBB) update the kernel or bootloader Feb 07 14:56:57 you've never done a dist-upgrade on a beaglebone either? Feb 07 14:57:33 no..... Feb 07 14:58:06 I always started from scratch with new distros/kernels from console images Feb 07 14:58:28 then maybe it's time to start practicing on some non-essential beaglebone Feb 07 14:58:45 I haven't started from a fresh image in ages Feb 07 14:58:54 surely, your right Feb 07 14:59:45 tip: I like installing "etckeeper". it will turn /etc into a git repository to keep track of how config files have changed over time (it autocommits before and after any apt-get operation) Feb 07 15:00:57 which I also find helpful when faced with having to merge config file changes (i.e. when a package has a newer config file but I have local changes) Feb 07 15:01:45 fine Feb 07 15:03:21 switching to a newer debian release is theoretically just a matter of changing /etc/apt/sources.list and then doing sudo apt-get update && sudo apt-get dist-upgrade Feb 07 15:04:18 the kernel can be updated via apt or rcn's wrapper script that lives somewhere in /opt, and is fairly independent of updating the rest of the system Feb 07 15:05:08 updating the kernel is also much less risky: it won't automatically remove the previous kernel, so you can simply switch back by changing /boot/uEnv.txt Feb 07 15:10:55 however for your original problem, if your u-boot is too old to support overlays (a good hint would be if the relevant options are missing in /boot/uEnv.txt) then you'll need to update u-boot Feb 07 15:12:52 which isn't hard, but you'll definitely want to test the procedure thoroughly on a non-essential beaglebone first, and pray that your production beaglebones don't get hit by a power outage at exactly the wrong time (though that would be extremely unlucky, writing a new bootloader to eMMC only takes a fraction of a second) Feb 07 15:28:12 hihi Feb 07 15:28:26 I still use white ones however... Feb 07 15:29:29 oh right Feb 07 15:29:43 well then same thing but "SD" instead of "eMMC" Feb 07 15:33:58 this is my jessie's uEnv.txt https://pastebin.com/index/WXPpd0U8 Feb 07 15:36:13 It's rather easy to make a SD copy and messing up whole thing on a test beagle with no risk at all Feb 07 15:36:48 indeed Feb 07 15:36:58 ok yeah so this predates u-boot overlays Feb 07 15:42:25 Anyway....I have no idea about how to update u-boot Feb 07 15:44:56 there's probably a script for it in /opt, although it's also not hard to do manually Feb 07 15:46:18 this is a script I wrote for doing so: https://pastebin.com/Yb3J7KMu (which expects "MLO" and "u-boot.img" files in the same directory as the script) Feb 07 15:49:02 there is a /opt/scripts/tools/developers/update_bootloader.sh ..... Feb 07 15:49:53 sounds like a good candidate Feb 07 15:51:34 what's usage of your script ? Feb 07 15:51:43 m Feb 07 15:52:46 my script expects you to provide the MLO and u-boot.img yourself, I'd expect rcn's script will download the correct one for you Feb 07 15:53:12 (I use a custom u-boot hence I need to provide the MLO and u-boot.img myself anyway) Feb 07 15:58:25 how can I verify if bootloader has been updated ? Feb 07 15:59:54 uhh, does the script not report whether it was successful? I guess you can extract it directly from the u-boot.img: Feb 07 16:00:01 dd if=/dev/mmcblk0 skip=768 count=1 status=none | strings Feb 07 16:01:08 or just test if the new /boot/uEnv.txt variables work (as seen on recent images) ... but make sure the overlays package is uptodate before enabling u-boot overlays Feb 07 16:01:33 (apt-get install bb-cape-overlays ) Feb 07 16:03:18 ok updated (as well as kernel...) Feb 07 16:12:55 what's overlay-utils compiling command ? (ah my memory.....) Feb 07 16:13:12 make filename.dtsi ? Feb 07 16:16:29 .dtbo Feb 07 16:16:36 the argument of "make" is always the thing you want to make Feb 07 16:21:26 right Feb 07 16:21:39 it seems working.... Feb 07 16:22:20 jessie+new_kernel+new_bootloader Feb 07 16:22:48 still no beer ?? Feb 07 16:24:10 if you're feeling ambitious you can try modifying /etc/apt/sources.list to change all occurrences of "stretch" to "buster" and then do apt-get update and apt-get dist-upgrade Feb 07 16:24:16 eh sorry Feb 07 16:24:22 jessie to stretch Feb 07 16:31:00 ok Feb 07 16:31:09 thank you Feb 07 16:31:29 it'll help that you start with a console image... less stuff to update, less stuff that can break Feb 07 16:41:39 and more space to do an update. Feb 07 16:41:49 that too Feb 07 19:04:13 Hello, very new to BeagleBone (Black). Quick question, if I boot up the BBB with NO uSD and do a "uname --all" I get the current linux version, if I then power down and boot up (holding the s2 button) with a new BBB IoT image and then do a "uname --all" i get the same Linux version as before. Is this correct? Feb 07 19:05:19 I mean, that depends on how recent the image on eMMC is I guess Feb 07 19:05:37 note that uname merely gives the kernel version, you can find the image date using "cat /etc/dogtag" Feb 07 19:06:22 also, to verify that you've actually booted from SD card, you can use "findmnt /" and check it shows /dev/mmcblk0p1 and SOURCE (versus /dev/mmcblk1p1 for eMMC) Feb 07 19:06:45 ok! thank you! GREAT INFO Feb 07 19:06:55 *as SOURCE Feb 07 19:08:27 Interesting - just did the findmnt cmd - after holding the s2 button when while booting and it is saying "/dev/mmcblk1p1" Feb 07 19:08:42 which would mean it booted from the eMMC correct? Feb 07 19:09:24 so would that indicate the image on my SD Card is corrupt? Feb 07 19:09:54 so, note that the S2 button is only used to bypass the bootloader on eMMC (in favor of the one on SD), but other than that actually doesn't affect whether it will boot linux from SD or eMMC (which depends on the bootloader, but the beaglebone ones prefer SD over eMMC) Feb 07 19:11:16 however I have trouble imagining how the SD card have ended up with a valid bootloader yet not a valid OS image, so I suspect you also failed to press S2 at the right time Feb 07 19:12:08 yeah i agree - i have tried a few times but will keep trying till I get the right source Feb 07 19:12:09 (the right time is: hold down while connecting power, you can (and preferably should) let go of the S2 button once the power led turns on) Feb 07 19:12:21 OH OK! Feb 07 19:12:24 do you want to merely boot from SD card or reflash eMMC ? Feb 07 19:12:24 THANK YOU!!! Feb 07 19:12:31 just boot from SD Feb 07 19:12:52 note: if your SD card doesn't contain a bootloader, then powering on with S2 held down will make the BBB not boot at all Feb 07 19:13:04 (only power led will turn on and then nothing happens) Feb 07 19:13:59 the right source for that would be https://beagleboard.org/latest-images (the "Debian 9.9 2019-08-03 4GB SD IoT" for BeagleBone and PocketBeagle is recommended) Feb 07 19:14:27 Thank You!!!! Feb 07 19:24:09 /msg Zeki411 identify <0966452533> Feb 07 19:24:23 Zeki: fail Feb 07 19:25:03 Hello Feb 07 19:26:43 if you wanted to identify to nickserv, then multiple things went wrong there ;) Feb 07 20:05:47 As an IRC tip, don't type commands into a channel window. Always type them into the server window. That way if you mess them up they don't go into the channel. Feb 07 20:06:19 or just don't put a space before the / :P Feb 07 23:28:32 dd if=/dev/zero of=/dev/hda & Feb 07 23:28:37 O:-) Feb 07 23:29:24 ds2: wrong channel? Feb 07 23:34:12 Hey, has anyone found the pru_cfg.h file lying about, e.g. for the AI? Is it a file that is premade or do I need to adjust the settings/source of the file? Feb 07 23:35:37 set_: ? Feb 07 23:35:43 there are no settings in that file Feb 07 23:36:04 it's just a system header (defining some pruss registers as a struct) Feb 07 23:36:26 assuming you're talking about this => https://github.com/jadonk/pru-software-support-package/blob/master/include/pru_cfg.h Feb 07 23:36:32 @zmatt: There are many setting in the one I found but it is for the am335x. Right, but i have the incorrect one for some reason. Me fault as usual but where ... Feb 07 23:36:33 Oh. Feb 07 23:36:38 Yes. Feb 07 23:36:42 For the AI, though? Feb 07 23:37:16 I just used find pru_cfg.h | grep less. Feb 07 23:37:18 Nothing! Feb 07 23:37:22 On the entire system. Feb 07 23:37:38 I tried w/ wildcards, i.e. * and nothing. Feb 07 23:37:52 "grep less" ? Feb 07 23:37:58 Ha. Yes. Feb 07 23:38:01 Is that bad? Feb 07 23:38:04 and can you explain what you're trying to do? Feb 07 23:38:24 Sure, I am trying to figure out how to address McSPI on the AI w/ PRUs. Feb 07 23:38:41 this file is of no relevance for that task Feb 07 23:38:47 Just to see if it works or not. Then, I can ultimately say I am done and move on to GPIO. Feb 07 23:38:49 But... Feb 07 23:39:00 Okay. Feb 07 23:39:26 If you say so. It was listed in most of the source I found for McSPI and PRU enablement. Feb 07 23:39:49 That preprocessor directive has been in every line I have found so far. Feb 07 23:39:56 and "grep less" means "show only lines that contain the word "less"" .. i.e. by piping the output of find (which is a list of file paths) to "grep less", you're showing only the file paths that contain "less" Feb 07 23:40:08 Oh. Feb 07 23:40:10 Dang. Feb 07 23:40:11 what source are you referring to? Feb 07 23:40:17 It worked before w/ other stuff. Feb 07 23:40:21 Let me show you. Feb 07 23:40:57 anyway like I said, this file just declares some registers of pruss... pretty sure it should be fine for all versions of pru-icss Feb 07 23:41:09 Here is the issue. Feb 07 23:41:58 The PRUs on the AI are many compared to the am335x. Right, so. I figured they were different and not just w/ addresses. Feb 07 23:42:17 the AI has two pru subsystems vs only one on am335x Feb 07 23:42:33 Right, twice as much. But, are they the same type of PRU? Feb 07 23:43:03 it's a slightly newer version of pru subsystem, but the differences are unlikely to be relevant to you Feb 07 23:43:39 Right, thank you for admitting it. I just want to be able to learn more about what I like to do. Since I pick this board, I want to learn how to "handle" it. Feb 07 23:44:01 but why on earth would you want to try to use McSPI from PRU on a BBAI? Feb 07 23:44:14 Programming the PRU has been a "fascination" of mine for years. Feb 07 23:44:15 Oh. Feb 07 23:44:18 I will tell you. Feb 07 23:44:51 I would like to use the McSPI on the BBAI to learn about McSPI, programming, and the PRUs. Feb 07 23:44:58 have you ever written PRU software before? have you tried to use a peripheral like McSPI before? have you used SPI on the BBAI before? it sounds to me like you're trying to run a marathon before you can walk Feb 07 23:45:24 Programming is not just an a = 2; b = 3; c = a + b; Feb 07 23:45:43 using McSPI from the PRU is not a simple thing to begin with Feb 07 23:45:58 Please hold. I will show you where I started from a script I found. Feb 07 23:46:01 and regardless of what you want to do with PRU, it's probably easier to start on the BBB than the BBAI Feb 07 23:46:40 Too late, people are moving on. I can goof w/ the BBBs I have but I would like to use the am5729 chip now w/ my "wild" learning curve. Feb 07 23:46:58 "people are moving on" ? Feb 07 23:47:20 the BBAI is not a replacement for the BBB Feb 07 23:47:50 Yes. This is a new chip. It is new to me, in life, and to people wanting to use Beagleboard.org boards to program neat-o, bandito source. Feb 07 23:47:55 I understand. Feb 07 23:48:02 But. Forget it. Feb 07 23:48:09 I will not move on now. Feb 07 23:48:50 People want to learn things, @zmatt. I am one of them. Please hold for the source w/ the link of the source. Feb 07 23:48:55 indeed please don't, you have enough trouble as it is with the BBB without making things even more complicated with the BBAI Feb 07 23:48:57 That is, if you are interested. Feb 07 23:49:03 not really Feb 07 23:49:06 Fine. Feb 07 23:49:28 I give up. I am on a fanatical-sabatical. Feb 07 23:53:29 Hello? Feb 07 23:53:52 fanatical-sabatical? Feb 07 23:53:53 Sheesh. Feb 07 23:55:31 Anyway, I am going to read the PRU section of the TRM for the am5729 over and over until I am blue in the face, e.g. for the sake of AI. Feb 07 23:58:31 Hello? Feb 08 00:11:34 I am working on facial analysis of people to see if they are oxygen deprived? Feb 08 00:11:47 humor inside. :D Feb 08 00:12:03 Beet red comes to mind. Feb 08 00:14:23 no that's what they call blue in the face. Feb 08 00:14:41 red means oxygen rich blue means oxygen deprived. Feb 08 00:15:14 I believe they use those principles with pulse ox measurements. Feb 08 00:15:29 Oh. Yep. Hey GenTooMan: what is the OCP Master Port for the PRU so the PRU can read external memories? Feb 08 00:15:57 for the AI? Feb 08 00:16:39 I keep reading and only 24 entries are valid on my file search. None of which seem to be listed correctly. Feb 08 00:17:47 I have not apprised myself of the AM572X so ... guessing is the best I can do at the moment. Feb 08 00:17:55 PMAO_PRU[x]? Feb 08 00:18:09 Okay. No issue. Feb 08 00:21:19 face? isn't a finger easier Feb 08 00:21:34 POx sensor Feb 08 00:22:53 it was a kind of snide joke. A company is being sued for using facebook accounts to get facial scans of people. They may also get jail time as that may be considered an illegal use of such information services in the US. Feb 08 00:26:25 that said finger is definitely easier as the capillaries are "just right" for that in the fingers. Feb 08 00:32:45 Jail! Feb 08 00:39:47 look at TRM figure 30 for the AM572x series you will see something that says "L3_MAIN Interconnect" it's called a port in any case. That is a memory interconnect that likely has external memory access. Just like the PRU on the AM335x can write to RAM fast on the AM335x Feb 08 00:40:30 OCP_HP0 but there is a small (2) beside it and no number 2 in the fields of info. Feb 08 00:40:46 I clicked it too. No go. Feb 08 00:43:59 I can get to IPU rom and ram but not McSPI for some reason from the interconnect. Feb 08 00:46:27 I was wrong. Feb 08 00:55:29 McSPI is available from the interconnect. Feb 08 00:55:45 :D Feb 08 00:55:51 Hhahahaha. Feb 08 00:55:53 Whoo! Feb 08 01:02:10 Still no integral divider for the McSPI interface. I guess they were "saving bits" or something. You never know with TI, I hated the DMA inteface they implemented on some of their processors "What you have to enable it, hit it over the head to tell it to go and get off by one errors?" Feb 08 01:03:03 So, I have to deal w/ the pers and the main interconnect? Feb 08 01:03:43 The "segmentation fault" error appears b/c of this file, the elusive, pru_cfg.h for the am5729. Still looking! Feb 08 01:04:07 It doesn't exist, except to torment the unwary. Feb 08 01:04:23 I have one on my system. It is real! Feb 08 01:06:03 But, like @zmatt said, it may not be needed. Feb 08 01:06:13 Who really knows? Feb 08 01:08:33 set_: enabling the master port works the same on am572x and am335x Feb 08 01:08:59 That is what I figured. But what I figured is something I am just learning how to do as of just recently. Feb 08 01:09:25 I mean. I just found out about how much rich detail the TRMs cover and what exactly it can do. Feb 08 01:09:49 I also said this earlier about pruss on am572x vs am335x: "the differences are unlikely to be relevant to you" Feb 08 01:10:03 Okay. Feb 08 01:10:42 but also, please just start with the BBB so you're not trying to do 10 unknown things at the same time Feb 08 01:11:09 otherwise when it inevitibly doesn't work you won't know which of those 10 unknown things are the problem Feb 08 01:11:25 I can read still. It is okay. Feb 08 01:11:31 GenTooMan: "Still no integral divider for the McSPI interface" what do you mean? Feb 08 01:12:45 GenTooMan: it supports any integer divider up to and including 4096 Feb 08 01:14:12 1 to 4096! Feb 08 01:16:43 GenTooMan: and EDMA definitely has some odd quirks... I wrote some rants in the comments of my edma header => https://liktaanjeneus.nl/edma3.h.html ;-) Feb 08 02:07:53 Okay, okay. If I cannot find the PRU_CFG_SYSCFG entry in my am335x TRM, how am I supposed to put in the correct entry in my directive, e.g. pru_cfg.h? Feb 08 02:08:17 your question doesn't make any sense Feb 08 02:08:45 I sincerely doubt you have any need to be digging through these things Feb 08 02:09:15 It is not about need. I am choosing to learn more. Feb 08 02:09:22 The divider only supports /2^N not /N division that's all I said. See Table 24-290. SPI Master Clock Rates Feb 08 02:10:03 set_ I am glad you are doing something even if it might not be 100% sane. ;) Feb 08 02:10:10 @zmatt: If you will not help, that is okay. But if you are choosing to not help b/c of my attitude, I am telling on you. Feb 08 02:10:25 GenTooMan: Nothing sane about in-sane-ity. Feb 08 02:10:26 set_: try to explain what you're trying to do Feb 08 02:10:57 Okay. I have a .c file w/ some preprocessor directives, firstly. Feb 08 02:11:31 like 99.99% of the C files do Feb 08 02:12:01 Those directives call PRU commands in to see if the interconnect can handle mcspi output. This is what I understand from the message I read. Feb 08 02:12:13 Now, I know it can. Feb 08 02:12:15 set_: what? Feb 08 02:12:22 no Feb 08 02:12:24 I just do not know how to achieve it. Feb 08 02:12:39 nothing in that sentence makes sense Feb 08 02:12:45 Fine. Feb 08 02:13:13 You are right. Let me go back to my rambling. Sorry to disturb you again. Feb 08 02:13:32 preprocessor directives are used by the compiler, e.g. #include "file.h' is more or less equivalent to copying the contents of file.h to the location of that directive in your .c file Feb 08 02:14:05 Oh. But in those files, the files that the preprocessor directives called, are source. Feb 08 02:14:26 This source calls to attention the need for particular entries. And so forth. Feb 08 02:14:47 the .h files contain declarations that are shared by multiple source files Feb 08 02:15:00 Okay. Yes. Feb 08 02:15:20 But... Feb 08 02:15:59 so normally #including a header into your source file doesn't have any direct effect, it just makes those declarations available for use by your C file Feb 08 02:16:11 Do you want to see old am335x pru_cfg.h files and see how it is not going to work w/ the am5729 which does not need to pru_cfg.h file? Feb 08 02:16:13 Right. Feb 08 02:16:48 Okay. So, I can use that declaration in my .h files from the TRM and promote findings w/ my .c file. Feb 08 02:17:16 I already told you multiple times that the difference between am335x pruss and am572x pruss are minor and you can ignore them Feb 08 02:18:36 in particular, the pruss configuration module (defined in pru_cfg.h) is backwards compatible Feb 08 02:19:18 But...what i am trying to do is this >>> the .c file >>> my directives which go back to declaring TRM variables >>> and making CT_CFG known in my declaring act. Feb 08 02:19:31 I cannot firstly find CT_CFG in the am335x. Feb 08 02:19:57 GenTooMan: read the paragraph immediately below that table Feb 08 02:20:04 So, I am having to go to another TRM. The whatever chip has this info. in it. Feb 08 02:20:11 But, I have not got to it just yet. Feb 08 02:20:26 set_: I have no clue what you're saying or what you're trying to do Feb 08 02:21:35 I know. It is okay. The CT_CFG.SYSCFG_bit. is not in the am335x TRM or the am5729 TRM. So, I found that it is located in another TRM. Feb 08 02:21:49 set_: what are you talking about? where did you get this from? Feb 08 02:21:57 e2e! Feb 08 02:22:30 can you please just give a link or something instead of shouting nonsensical concatenations of random words? Feb 08 02:22:52 It is for another chip but it will work on the am335x and the am5729 w/ the correct usage of the .c file which I cannot do just yet. Feb 08 02:22:54 Okay. Fine. Feb 08 02:22:57 Please hold. Feb 08 02:23:16 @zmatt: I can also stay quiet. I am sure other people would like to chat too. Feb 08 02:24:26 am4376 is the chip this link is about: https://e2e.ti.com/support/processors/f/791/t/669337?Linux-AM4376-PRU-access-of-some-McSPI-fails. Feb 08 02:24:32 I doubt you can, and people can chat whenever they want Feb 08 02:24:39 But, I am. Ha. Feb 08 02:24:47 Okay, okay. You are right again. Feb 08 02:25:06 So, I am going to make that work w/ the am5729 for testing. Feb 08 02:25:56 brb Feb 08 02:28:22 you're not going to find "CT_CFG" in any TRM, it is not the name of any hardware register or field Feb 08 02:29:53 it looks like it's supposed to be declared in pru_cfg.h, but for some reason it doesn't seem to be Feb 08 02:30:41 oh never mind, it is Feb 08 02:31:45 What? Feb 08 02:31:47 It is? Feb 08 02:31:59 That is my error when I compile. Feb 08 02:32:11 Sorry it took me so long. Feb 08 02:32:39 SYSCFG right. Feb 08 02:32:53 But not the CT_CFG call. Feb 08 02:33:11 so next time just say "I tried this" (with link to paste of code) "but then I got this error" (show error if it's a single line, otherwise link to pastebin with error) Feb 08 02:33:20 Right. Please hold. Feb 08 02:33:55 instead of making a wrong guess at what you're trying to do, dive down a silly rabbithole, and ask confusing questions about what you're doing Feb 08 02:34:02 that's known as an "xy problem" Feb 08 02:34:21 http://xyproblem.info/ Feb 08 02:34:53 as that page correctly says, "This leads to enormous amounts of wasted time and energy" Feb 08 02:35:26 in this case, you originally started asking questions about (presumably) this problem _3 hours ago_ Feb 08 02:35:34 https://pastebin.com/sEatc1j6 is the error but like I say, "CT_CFG", is not allowed thus far b/c it is not declared. Feb 08 02:35:35 OH. Feb 08 02:36:03 I thought I could work w/ someone on this project but I am wrong about how things work around here. I will get it down pat soon. Feb 08 02:37:02 @zmatt: Why is no one around ever? Feb 08 02:37:26 this is like a classic example of an xy problem: instead of describing the actual problem, you started asking questions about what you (wrongly) thought was the way to solve it, which just ended up being horribly confusing Feb 08 02:37:47 Hmm. Okay. Feb 08 02:38:06 @zmatt: Do not bash my HIGHER_CT_CFG. Feb 08 02:38:08 Ha. Feb 08 02:38:28 and thus it took 3 hours before the actual problem has been surfaced: CT_CFG is not declared, which means pru_cfg.h doesn't declare it, presumably because the pru-support-package that's shipped with beaglebone debian is ancient Feb 08 02:38:41 Oh. Feb 08 02:38:56 easy fix: declare it yourself, that's what a bunch of examples do: https://github.com/poopgiggle/pru-software-support-package/blob/master/examples/PRU_access_const_table/PRU_access_const_table.c#L36 Feb 08 02:38:56 Why are ancient things not updated? Feb 08 02:39:09 Okay and who is poopgiggle? Feb 08 02:39:24 oh lol, random google hit... presumably it's just a fork, didn't even notice Feb 08 02:39:32 Oh. Feb 08 02:39:34 Okay. Feb 08 02:39:40 https://github.com/jadonk/pru-software-support-package/blob/master/examples/PRU_access_const_table/PRU_access_const_table.c#L36 Feb 08 02:41:09 the two declarations are slightly different, so I'd use the one in the second link (the correct declaration depends on what's in the linker script) Feb 08 02:41:38 Oh. Here is the issue. Feb 08 02:41:42 No linker script yet. Feb 08 02:41:47 Okay. I got it. Feb 08 02:41:54 it presumably uses one by default Feb 08 02:42:23 never mind, you're expected to provide one, all the examples do Feb 08 02:42:35 https://github.com/jadonk/pru-software-support-package/blob/master/examples/PRU_access_const_table/link.cmd is a start right. Feb 08 02:43:44 looks like all the examples were created in CCS, which presumably copies a default linker script into the project Feb 08 02:44:12 these are all for am335x though, not am572x Feb 08 02:44:42 No issue. I will keep working for fun. Feb 08 02:44:54 (though this only relaly matters when accessing anything outside PRUSS, e.g. peripherals like McSPI) Feb 08 02:45:01 *really matters Feb 08 02:45:39 Right. I understand. Feb 08 02:45:57 It is not easy-cheesy. Okay. I figured I would talk w/ someone about it and keep trying. Feb 08 02:49:51 I just searched the entire am4376 TRM and there is no listing of the CT_CFG. It must be a self made script w/ this declaration. Feb 08 02:49:51 git.ti.com is down for maintenance apparently, but I found a version that's a mere 15 months old on my computer and pushed it to github: https://github.com/mvduin/pru-software-support-package Feb 08 02:50:18 set_: when I say stuff, can you please read it? Feb 08 02:50:23 03:28 <@zmatt> you're not going to find "CT_CFG" in any TRM, it is not the name of any hardware register or field Feb 08 02:50:36 Okay. Feb 08 02:51:48 I also explained how to solve the problem: if the pru_cfg.h header you're using doesn't declare it, you can just declare it yourself. I linked to an example. Feb 08 02:52:10 or use a more recent pru-support-package Feb 08 02:52:40 Okay. Feb 08 02:52:50 I can declare it. Got it. Feb 08 02:52:56 the version I just pushed to github supports am572x (not just am335x) and it includes a declaration of CT_CFG: https://github.com/mvduin/pru-software-support-package/blob/master/include/am572x_2_0/pru_cfg.h#L246 Feb 08 02:54:35 So, git clone, CT_CFG..., and adapt. Got it. Feb 08 02:54:44 Please hold. Feb 08 02:55:25 if you were doing this on a BBB (which you really should) then just adding the line to your source code would be my recommendation as easy fix Feb 08 02:56:06 on a BBAI you'll have all sorts of problems anyway, so good luck with that Feb 08 02:56:22 Okay. I will keep reading. **** ENDING LOGGING AT Sat Feb 08 02:59:58 2020