**** BEGIN LOGGING AT Tue Jul 07 02:59:58 2020 Jul 07 03:00:47 Good night. Jul 07 03:01:07 later Jul 07 03:15:12 a struct definision should be a seperate file from the c code Jul 07 03:15:21 definition Jul 07 03:18:52 no, the purpose of a header file is just to be able to reuse definitions between multiple C files Jul 07 03:19:26 but there's no semantic difference between putting something directly in the c file versus putting it in a header file and #including that Jul 07 03:26:56 I should declare the struct as far even though you reference the shared base address Jul 07 03:27:16 I can't parse that sentence Jul 07 03:27:31 so I made a three variable struct Jul 07 03:28:09 the define statement underneath creates the type ? Jul 07 03:28:29 how does that look like a type to you? Jul 07 03:28:31 I guess I am asking do I need to declare the struct beyond the #define statement Jul 07 03:28:32 the struct is the type Jul 07 03:29:01 the #define statement doesn't declare any struct, it _uses_ the struct declared right above it Jul 07 03:29:16 the #define I mean, it's not a statement Jul 07 03:29:30 so I am free to use it after the #define statement. I am confused by the foo variable Jul 07 03:29:58 and whether I need to have a far used Jul 07 03:30:00 what do you mean by "use it" ? the role purpose of the struct in that example was to use it in that #define Jul 07 03:30:25 which defines a macro for a pointer to the shared memory region Jul 07 03:30:37 but, what are you trying to do? Jul 07 03:31:01 I am just going to read the load value into my load variable in the struct Jul 07 03:31:24 because that snippet was just an example to show accessing another PRU core's memory would generalize if you have multiple variables, but you don't Jul 07 03:31:30 the encoder only has a single output Jul 07 03:31:42 *decoder Jul 07 03:32:08 right I am trying to generalize because I would like python to pull three variables from shared Jul 07 03:32:21 the counter from the decoder Jul 07 03:32:29 laod from the uart Jul 07 03:32:36 and a time Jul 07 03:32:42 a time? Jul 07 03:32:42 which is just a counter Jul 07 03:32:51 time elapsed Jul 07 03:33:20 in seconds Jul 07 03:33:34 i have a uint64 variable for that Jul 07 03:33:36 in seconds? where would you even get that from, and for what purpose? Jul 07 03:34:10 i was going to try and make one, I want to track how long the motor has been spinning Jul 07 03:34:28 i take it, I should just do this from python Jul 07 03:34:29 lol Jul 07 03:34:35 i will delete Jul 07 03:34:41 so just two variables Jul 07 03:34:51 I thought your goal was for the whole thing to be running on the pru core? Jul 07 03:34:56 the control loop Jul 07 03:35:10 yeah Jul 07 03:35:28 forget I said anythign Jul 07 03:35:48 I do need to have some info periodically populate the gui Jul 07 03:36:01 so I wanted to write to shared and have python reach in and get the data Jul 07 03:36:15 anyway, for variables that are "owned" by your C program that you want to export to python it probably makes more sense to declare normal variables and use the location attribute Jul 07 03:36:54 sure, although you don't need the position-counter since python can simply read that from the decoder PRU's memory Jul 07 03:37:34 ok probably same for the load, but this to pass between PRUs Jul 07 03:37:38 which I still would want to do Jul 07 03:37:47 and I would only need the decoder from PRU0 Jul 07 03:37:57 "ok probably same for the load, but this to pass between PRUs" ?? Jul 07 03:38:25 no Jul 07 03:38:35 that is only needed by the control loop Jul 07 03:38:45 nothing needs to be passed to the PRU0 doing the decoding Jul 07 03:38:53 correct, hence my "??" Jul 07 03:39:36 i confuse myself sometimes Jul 07 03:41:54 so I am going to add that struct to the decoder.pasm file Jul 07 03:42:20 and I would just move the value from the registry to that new variable in shared memory Jul 07 03:43:02 I could just add a line to the increment and decrement macros right? Jul 07 03:45:16 what? Jul 07 03:45:17 no? Jul 07 03:45:37 why do you think you need to modify the decoder? the decoder is fine Jul 07 03:45:55 the decoder has no need to know about your structs Jul 07 03:46:33 so the counter is in registry10 Jul 07 03:46:38 it maintains the counter in its own memory, where both python and your C program can read it whenever they want Jul 07 03:48:49 registry are different from memory right? Jul 07 03:49:00 I have no idea what you mean by "registry" Jul 07 03:49:15 r10 Jul 07 03:49:39 those are called registers, and not something you need to worry about in C code Jul 07 03:50:03 ok Jul 07 03:50:07 and yes they are different from memory Jul 07 03:50:34 so far as C is concerned r10 is memory and I can see it with my struct Jul 07 03:50:38 no Jul 07 03:51:20 so far as C is concerned registers are invisible, a behind-the-scenes detail that only matters to the compiler Jul 07 03:51:47 you have no reason to care about what registers are being used for what Jul 07 03:52:11 so r10 is just in PRU0 memory Jul 07 03:52:20 I have no idea what you're even talking about Jul 07 03:52:30 there is no "r10" in C code Jul 07 03:52:34 i will just forget the registry and r10 Jul 07 03:52:53 in my C code the way the struct is defined it will pick up the counter Jul 07 03:52:56 where are you getting any of this from? what's your obsession with r10 ? Jul 07 03:53:26 to access the counter you don't need any struct Jul 07 03:54:01 well for PRU1 Jul 07 03:54:18 I would like to read it Jul 07 03:54:45 *(uint32_t volatile *)0x2000 Jul 07 03:55:00 will return the current counter value Jul 07 03:56:07 https://pastebin.com/e9Vf1UPT Jul 07 03:56:52 right to me it is pure magic on how they link up. I will not belabor the point now. I am also confused to high hell why shared_dram.map would also get the counter value Jul 07 03:59:05 oh you're still using shared_dram for the decoder? I know I mentioned that it was probably a better idea to use the decoder PRU's private dram, but I don't know if you made that change; use "c24" instead of "c28" in the PRU code and core.dram instead of core.shared_dram in the python code Jul 07 04:01:12 ok Jul 07 04:12:06 MattB00ne: https://pastebin.com/RtWb95EG Jul 07 04:13:14 this is a nice cheat sheet Jul 07 04:13:44 MattB00ne: btw I also pushed a small change, in my small C example (test.c) I now explicitly configure the addres of the shared-memory variable it declares Jul 07 04:14:12 something like that can be used for the info you want your C code to make available for the GUI and/or debugging Jul 07 04:14:13 ok Jul 07 04:14:19 perfect Jul 07 04:14:22 i will play with it Jul 07 04:15:04 (you can either declare multiple variables at individual addresses, making sure there's no overlap, or more conveniently declare a single struct with everything you want to share and create a single variable of that struct) Jul 07 04:16:25 so anyway, if the decoder program writes the counter to offset 0 from c24, that means offset 0 from its core.dram, hence python can access that counter with core.dram.map( u32, 0 ) Jul 07 04:16:41 ok I see Jul 07 04:16:55 that is what I needed. How they all connect Jul 07 04:17:11 while for the C program core it's the "other core's memory", hence address 0x2000 Jul 07 04:17:42 (hence https://pastebin.com/e9Vf1UPT ) Jul 07 04:18:18 ok. That is enoguh hand holding for tonight. I am going to mess with this and come back with problems with my code tomorrow =) Jul 07 04:18:26 thanks this was big help **** BEGIN LOGGING AT Tue Jul 07 04:29:42 2020 **** BEGIN LOGGING AT Tue Jul 07 05:22:32 2020 **** BEGIN LOGGING AT Tue Jul 07 05:56:27 2020 **** BEGIN LOGGING AT Tue Jul 07 10:14:46 2020 **** BEGIN LOGGING AT Tue Jul 07 11:21:02 2020 Jul 07 12:11:00 Hello, Jul 07 12:11:54 hello sir Jul 07 12:17:54 amine82: the events used are listed as interrupts on the two pru nodes in DT Jul 07 12:18:05 though I'd need to check which one is "vring" and which one is "kick" Jul 07 12:18:58 where can i find the device tree containing this declaration Jul 07 12:19:26 * PRU0 uses system event 16 (To ARM) and 17 (From ARM) Jul 07 12:19:42 it's in am33xx.dtsi Jul 07 12:19:58 in /lib/firmware folder ? Jul 07 12:20:46 "vring" is pru->arm and "kick" is arm->pru Jul 07 12:21:40 I've flashed my BeagleBone Black with "AM3358 Debian 10.3 2020-04-06 4GB eMMC IoT Flasher" image.Powered the BBB with 5V power supply and conected it via USB to my PC.Used following command to establish connection: "ssh 192.168.7.2 -l debian" Jul 07 12:21:50 Following will appear:Debian GNU/Linux 10BeagleBoard.org Debian Buster IoT Image 2020-04-06Support: http://elinux.org/Beagleboard:BeagleBoneBlack_Debiandefault username:password is [debian:temppwd]debian@192.168.7.2's password: Jul 07 12:21:54 amine82: no, in the device tree sources, which you can find in the kernel source tree in arch/arm/boot/dts/ or more conveniently here: https://github.com/beagleboard/BeagleBoard-DeviceTrees/blob/v4.19.x-ti/src/arm/am33xx.dtsi#L1152-L1174 Jul 07 12:22:00 Following will be shown after I put in th epassword:The programs included with the Debian GNU/Linux system are free software;the exact distribution terms for each program are described in theindividual files in /usr/share/doc/*/copyright.Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extentpermitted by applicable law.Last login: Mon Apr Jul 07 12:22:01 6 13:34:56 2020 from 192.168.7.2After that I fall back to my bash. Jul 07 12:22:32 lecram: please don't try to paste multiline text into chat, use a paste service like pastebin.com to share that Jul 07 12:23:03 ups, sorry Jul 07 12:23:11 though I'm not sure why you're sharing the standard login emssage Jul 07 12:23:13 *message Jul 07 12:23:19 what's your actual question? Jul 07 12:23:30 oh, maybe the relevant part got truncated Jul 07 12:23:33 zmatt : thakyou i will check it Jul 07 12:23:51 I fall back to my bash after login via ssh Jul 07 12:24:06 what can I do ybout that? Jul 07 12:24:08 amine82: you can also fish it out of /proc/device-tree/ .. but checking the source code is definitely easier :P Jul 07 12:24:19 lecram: is no error message printed? Jul 07 12:24:26 no Jul 07 12:24:52 o.O Jul 07 12:25:49 can you try: ssh debian@192.168.7.2 df -h Jul 07 12:26:03 sure Jul 07 12:26:20 (and share its output via pastebin.com or some other paste service) Jul 07 12:26:32 ok Jul 07 12:27:00 this will disconnect me from freenode. I will get back to you. Thanks for now. Jul 07 12:27:36 huh Jul 07 12:27:37 why? Jul 07 12:28:10 zmatt: are you sure you're prepared for the answer? Jul 07 12:28:25 some things you're better off not knowing Jul 07 12:28:27 lol Jul 07 12:40:38 zmatt: https://pastebin.com/zsrpaL5j Jul 07 12:40:48 lecram: why did you have to disconnect from freenode? Jul 07 12:41:38 I'm using the the same machine to connect to freenode and the beagle Jul 07 12:41:43 so? Jul 07 12:42:32 normally there's no problem staying connected to the internet while also being able to reach the beaglebone Jul 07 12:42:45 how can I manage that? Jul 07 12:43:10 ehm, normally there's not anything to "manage" other than plugging in the beaglebone via usb Jul 07 12:43:15 what OS are you using? Jul 07 12:43:24 debian Jul 07 12:44:40 you're using gnome network-manager as network manager I assume? (if you don't know, you probably are) Jul 07 12:45:59 what IP range does your local network use? (if unsure, check using "ip addr -4") Jul 07 12:46:30 make that "ip -4 addr" Jul 07 12:47:05 you're right, my bad Jul 07 12:47:18 yes I'm using network-manager-gnome Jul 07 12:47:43 lecram: the only reason I can think of why the BBB might interfere with your internet access would be is if your local network uses an IP range which happens to conflict with the ones used by the BBB (192.168.6.x and 192.168.7.x) Jul 07 12:48:20 no it is 192.168.2.x Jul 07 12:48:48 so what happens exactly, if you plug in the BBB you lose internet access? Jul 07 12:48:58 no Jul 07 12:49:13 but I have to choose to connect to the BBB network Jul 07 12:49:23 this whill then disconnect me from the internet Jul 07 12:50:56 unfortunately I haven't used gnome network manager in ages, and don't have a machine around that uses Jul 07 12:52:03 ok, I will deal with that later or I will simply use another machine to connect to my BBB Jul 07 12:52:56 but for now can you say why my ssh connection doesnt work Jul 07 12:54:36 try turning on this option for the beaglebone's connection: https://i.imgur.com/kXPOm7s.jpg Jul 07 12:54:44 maybe that helps Jul 07 12:54:55 for being able to connect to both bbb and internet I mean Jul 07 12:55:18 as for your ssh issue, I honestly have no idea, I've never seen or heard of an issue like that Jul 07 12:56:14 clearly it could run the df command just fine, and you have plenty of free space Jul 07 12:58:23 try: ssh -v debian@192.168.7.2 and share the output via pastebin Jul 07 12:58:48 mru: I don't suppose you happen to use gnome network manager? :) Jul 07 12:58:56 nope Jul 07 12:59:01 I use dhcpcd Jul 07 12:59:02 It seems the normal motd appears on login, and the df command runs. I'm missing what the issue is? I re-read history and it hasn't helped, which usually implies I'm missing something. Jul 07 12:59:30 Ragnorok: his connection apparently closes right away Jul 07 12:59:35 Ah! Jul 07 13:00:36 I manged to connect to both internet connection and BBB but now I get a ssh connection refused Jul 07 13:01:13 That's what "fall back to my bash" meant. I took that to mean the B'bone was at a bash prompt. lol Would dmesg or so yield clues? Jul 07 13:01:25 that seems unlikely Jul 07 13:01:52 lecram: please share the output of the "ip addr" and "ip route" commands on your computer Jul 07 13:02:58 hmm actually "Use this connection only for resources on its network' should have no effect since the BBB offers no default route anyway Jul 07 13:03:57 zmatt: https://pastebin.com/raw/cdxuZvhd Jul 07 13:04:34 ehh that looks broken Jul 07 13:04:53 zmatt: https://pastebin.com/raw/MxrTySJf Jul 07 13:05:03 how on earth did your computer end up having both 192.168.7.1 and 192.168.7.2 as IP ? Jul 07 13:05:27 you must have done something weird with network settings? Jul 07 13:05:34 it should just be set to obtain address automatically Jul 07 13:06:12 the .2 is marked "secondary" Jul 07 13:06:17 whatever that means Jul 07 13:06:28 I was just wondereing about that. I think that's the multi-ip binding thing. Jul 07 13:06:41 "multi-ip binding thing" ? Jul 07 13:06:45 having extra IP addresses shouldn't hurt though Jul 07 13:06:54 More than one IP can be bound to a NIC. Jul 07 13:06:55 I have quite a few on my computer Jul 07 13:07:15 But .1 is preferred. It may affect how it connects. Jul 07 13:07:15 Ragnorok: I know it can, but why is his computer using the IP address that the beaglebone also uses? :P Jul 07 13:07:26 because that's going to make the beaglebone unreachable Jul 07 13:07:44 and honestly that can only have happened due to (incorrect) manual configuration Jul 07 13:07:48 oh, the beagle is using that address.. that's bad Jul 07 13:07:55 Ah. That's not the B'bone. Probably needs to adjust network settings to remove the secondary? Jul 07 13:08:01 here with unpluged BBB USB cable: https://pastebin.com/raw/1vK4JiEB https://pastebin.com/raw/u77hd4J8 Jul 07 13:08:35 lecram: it looks like you've misconfigured the network interface corresponding to the beaglebone Jul 07 13:08:40 the command "ip route get 1.1.1.1" can be helpful to how the computer is trying to reach the internet Jul 07 13:09:22 "default via 192.168.2.1 dev enp0s25" .. that's fine Jul 07 13:10:09 zmatt: in fact I just connected the BBB via USB and simply did a connection atempt to it via ssh. Did not really configure anything before Jul 07 13:10:54 lecram: I mean, between last time you were able to log in to the beaglebone and right now you must have changed the network config, since https://pastebin.com/raw/cdxuZvhd makes no sense Jul 07 13:11:24 what did you do when you said "I manged to connect to both internet connection and BBB but now I get a ssh connection refused" Jul 07 13:11:52 oh right Jul 07 13:12:20 no manual IP configuration should be needed Jul 07 13:12:33 just obtain IP address automatically Jul 07 13:12:41 ok Jul 07 13:15:08 Thanks for your support so far. Have to leave now. Will see if I can solve my ssh problem later. Bye Jul 07 13:15:25 did you see my request earlier? Jul 07 13:15:32 14:58 <@zmatt> try: ssh -v debian@192.168.7.2 and share the output via pastebin Jul 07 13:16:27 also, if you're in a situation where you're connected to the BBB but not internet, try to see if "nmcli con up id enp0s25" helps Jul 07 13:16:35 oh he left Jul 07 13:16:42 some people have the weirdest problems Jul 07 13:17:02 don't say I didn't warn you Jul 07 13:17:14 I just realized I should probably have asked what version of debian... maybe he's using some aaaancient version of network manager Jul 07 13:17:31 debian is ancient by definition Jul 07 13:17:32 Hey. I can help with aaaancient debian problems. ll Jul 07 13:17:50 they seem to think bugs evaporate over time Jul 07 13:17:50 I'm pretty sure in current versions of network manager the bbb should just work plug & play Jul 07 13:18:09 making really old versions nearly bug-free Jul 07 13:30:20 ok, For Science I just installed network-manager :P let's see what happens when I connect a BBB via usb Jul 07 13:31:37 it immediately brings both interfaces of the BBB up, I can ssh into the BBB, and I still have internet Jul 07 13:32:01 so yeah, It Just Works, as expected Jul 07 13:32:52 so either he manually broke it, or his network manager is very ancient (I saw a bug report from 2012 mentioning inability to use multiple interfaces) Jul 07 13:33:16 anyway, time to purge this crap from my laptop again :P **** BEGIN LOGGING AT Tue Jul 07 13:52:37 2020 Jul 07 14:55:50 m Jul 07 16:48:14 enp0s25, what happened to s01 to s24? Jul 07 16:48:56 systemd ate them Jul 07 16:50:15 I mean, it's just some systematic naming scheme Jul 07 16:51:23 systematically unguessable Jul 07 16:53:10 I'm not a fan either, but I understand the reasoning Jul 07 16:53:31 to fuck with _everything_? Jul 07 16:54:10 no, to have consistent names that won't change if you add some more hardware or the devices happen to get probes in a different order Jul 07 16:58:27 but now things get renamed if you move a single nic or whatever from one slot to another Jul 07 16:58:42 maybe to make room for something unrelated Jul 07 17:01:35 yep, the various naming schemes all have pros and cons. like I said, I'm not a huge fan myself, I've disabled systematic naming on my laptop Jul 07 17:01:54 Ohhh Jul 07 17:01:57 but I can imagine there are situations where you'd much rather have consistent naming Jul 07 17:02:12 I wouldn't mind it so much if the names weren't both extremely unwieldy _and_ completely unguessable Jul 07 17:02:43 Hi everyone Jul 07 17:02:52 I mean, with tab completion it doesn't matter that much Jul 07 17:03:18 harder to remember which of the very long names go to which nic Jul 07 17:04:13 I maen, if you have better identifiers that are meaningful to you, just use those. nobody is forcing you to use any particular naming scheme :P Jul 07 17:04:33 no, but they sure try their best to Jul 07 17:04:52 aaaand shani sent me a private message, and then left mere seconds later Jul 07 17:04:56 -.- Jul 07 17:05:40 I've never felt like anyone was trying to force it... the distro picks the default, and if you don't like it just change it **** BEGIN LOGGING AT Tue Jul 07 17:48:59 2020 Jul 07 19:11:33 I'm having a problem I can connect over wifi from a SBC. However if I try to wifi into the SBC it faile. I am pinging 192.168.55.38 and the failed return address is 10.128.128.128?? Jul 07 19:24:51 what is the exact error? **** BEGIN LOGGING AT Tue Jul 07 19:57:41 2020 Jul 07 20:00:26 sounds like maybe NAT in the way Jul 07 20:00:44 or general routing confusion Jul 07 20:00:56 seems to be a lot of that today Jul 07 20:23:20 So I rebuild my kernel b/c for some reason CONFIG_MODULE_UNLOAD wasn't set, so I'm seeing wonky numbers in lsmod. I unset FULL_REBUILD b/c I don't want it do that every time, and I set AUTO_BUILD so it doesn't run make_menuconfig. When the build is done, what is in KERNEL/.config does not match deploy/config-. What have I done wrong? Jul 07 20:24:07 what system are you using to build the kernel? Jul 07 20:24:17 some debian voodoo? Jul 07 20:24:40 I'm running build_deb.sh from a distro it pulled down the first time I built it. Jul 07 20:24:55 So probably some Debian voodoo. lol Jul 07 20:25:06 I find it easiest to build the kernel without any such contrivances Jul 07 20:26:09 the kernel's own build system is pretty good at rebuilding only what's needed Jul 07 20:26:18 if you try to defeat it, you're likely to screw up Jul 07 20:26:54 Ragnorok: that sounds odd Jul 07 20:27:19 Ok. My xp is build_deb.sh sucks at that. I like having the installable thing that once built, Just Works (tm) Jul 07 20:27:21 Ragnorok: wait, did you use build_deb.sh or tools/rebuild_deb.sh ? Jul 07 20:27:32 I did not use rebuild. Jul 07 20:28:01 build_deb.sh creates a freshly patched source tree Jul 07 20:28:21 Not if FULL_BUILD is unset. Jul 07 20:28:22 (hence will also compile from scratch) Jul 07 20:29:00 I... don't even see that setting in system.sh ? Jul 07 20:29:05 So it seems I should do a simple make call, then do rebuild_deb to pakcat it up. Jul 07 20:29:35 It's not. I had to edit build_deb.sh to unset it. For some reason it's hard-coded to always be 1, then it runs an if statement as if it's not hard-coded. Jul 07 20:29:36 tools/rebuild_deb.sh will already do "make" for you Jul 07 20:29:46 Ok. Guess I'll try that then. Jul 07 20:29:50 okay that sounds like something I wouldn't mess with then :D Jul 07 20:31:10 It only makes it bypass the git/patch bits, which are utterly unecessary as it did that very recently. Jul 07 20:31:18 tools/rebuild_deb.sh is what you'd use to tweak kernel config (with AUTO_BUILD unset) or after making changes toe the kernel source Jul 07 20:31:29 Ok. Jul 07 20:35:46 I see the problem. The file config- file it put in deploy also does not match what's in the .deb. When I extract that, it's the one I expected. Jul 07 20:36:21 build_deb.sh / tools/rebuild_deb.sh doesn't put a config-$uname_r file in deploy/ Jul 07 20:36:36 I'm guessing that might be from build.sh ? Jul 07 20:36:57 Ok. I see one there, but since I know it's not relevant now, I'll ignore it. lol Jul 07 20:38:27 maybe just remove it to avoid confusion Jul 07 20:39:54 Done!