**** BEGIN LOGGING AT Wed Aug 17 02:59:56 2022 Aug 17 12:22:04 if i know that some result in the pru is inside the r4 register , how do i write that into a c-variable ?? Aug 17 12:22:52 i am trying to make use of this https://nerdhut.de/2016/06/18/beaglebone-clock-cycle-counter/#comments but i do need the result of the counter in a c-var Aug 17 13:00:45 there are C intrinsics for doing this Aug 17 13:01:39 beware btw that the cycle counter should typically not be used for any purpose other than debugging/profiling since it doesn't wrap after reaching 0xffffffff (the cycle counter just disables instead) Aug 17 13:01:57 e.g. if you want to make timers, I'd suggest using eCAP or IEP Aug 17 13:02:25 I think I have example C code for that somewhere... Aug 17 13:12:28 rob_w: yeah https://pastebin.com/PhSU0kPc has some examples of getting timestamps using eCAP ... but it assumes py-uio is used for initialization, let me quickly add an example on how to do the initialization on pru itself Aug 17 13:16:01 well i wanted to make use to measure a loop and compensate for the various loop times with asm ( "nop") to reach a constant reentry of the loop itself Aug 17 13:16:14 i read the i can reset the counter and restart it every loop .. Aug 17 13:16:29 what would be those intrincsics zmatt ? Aug 17 13:21:27 zmatt yeah, I now see having resolveconf install is the issue. Sounds like the user ran an "apt install dhdpcd5" in order to solve his problem before asking me... Aug 17 13:23:05 zmatt Thank you for the solution :-) Aug 17 13:27:54 spout: generally my solution for solving networking issues is just removing connman and every other network manager package and use systemd-networkd instead ;) Aug 17 13:29:24 My first solution would have been to remove it and install dhcpcd instead. But then I read online that removing connman was a pain in the ass ? Aug 17 13:29:35 rob_w: what you're describing sounds like you want a timestamp counter that doesn't stop working after a while, which the cycle counter is not ;) but the eCAP counter is a good use for that... I just added (untested) initialization code to: https://pastebin.com/PhSU0kPc Aug 17 13:29:56 spout: here are my notes for replacing connman by systemd-networkd: https://pastebin.com/3tjj3v3R Aug 17 13:30:12 this assumes you're using debian buster Aug 17 13:30:15 I'ts just I have a software running on raspis, but now we're switching to beagles because of shortage, and there is little things like these that are different :-) Aug 17 13:30:19 (debian bullseye images already use systemd-networkd) Aug 17 13:30:39 of course you can use any network manager you want, it's just a debian system Aug 17 13:30:53 systemd-networkd works with dhcpcd ? Aug 17 13:31:26 I have no idea what dhcpcd is, systemd-networkd does dhcp itself Aug 17 13:32:11 dhcpcd is the name I give to the thing where you change the dhcpcd.conf file in /etc/ and you can set your ip, subnet, gateway and dns Aug 17 13:32:22 i tought it was linked to a package named dhcpcd5 ? Aug 17 13:32:49 uhh, that doesn't make sense... if you're using manual network configuration, why would you be using a dhcp client? Aug 17 13:33:03 the point of dhcp is _not_ having to configure any of those things Aug 17 13:33:40 (i.e. just plug it into the network and have it work) Aug 17 13:36:21 ok, I think I'm a little lost and confused by the roles of dhcp client, network manager, etc.:-O Aug 17 13:37:02 a network manager is the general term of a piece of software that manages your network interfaces Aug 17 13:37:15 it will generally either embed a dhcp client or invoke an external one Aug 17 13:37:39 dhcp is the protocol used to obtain an ip and network settings from the router on your network Aug 17 13:37:49 avoiding the need for manual ip configuration Aug 17 13:38:13 systemd-networkd and connman are examples of network manager Aug 17 13:38:15 s Aug 17 13:38:57 and so, switching your config from static to dhcp is the job of the network manager, but for the dhcp part it will ask the dhcp client to go ask his server. Right ? Aug 17 13:40:04 zmatt: so your saying this ... " To clear the count, the counter has to be reset (disabled and then enabled again) or the PRU has to be disabled" ,.. doesnt work ? Aug 17 13:40:37 But then, what is the thing in setting a static ip address in dhcpcd.conf  ( https://wiki.archlinux.org/title/dhcpcd ) ? Is it so your dhcpclient can query the server saying "hey, i want you to assign me that ip" ? Aug 17 13:43:48 rob_w: example how you might use my eCAP example to call something periodically in a loop: https://pastebin.com/5LW2ypX8 Aug 17 13:45:10 rob_w: I guess this particular dhcp client has experienced feature-bloat and is sort of a network manager on its own :P Aug 17 13:46:44 I've never used it nor even heard of it, you're the first person I've seen to mention it, so I can't really provide much insight on that particular piece of software Aug 17 13:49:25 rob_w: I suggest not messing with the cycle counter, just use the eCAP counter instead... it has the same resolution, has only one cycle of additional read latency (4 cycles instead of 3 cycles), and doesn't have the problem of having to disable/reset/reenable the counter to keep it from freezing up after a while Aug 17 13:49:57 the cycle counter is really just meant for performance profiling by a debugger Aug 17 13:50:07 not for general purpose timers Aug 17 13:57:34 ok i hear u Aug 17 14:00:22 well i am actually profiling my performance ... at least thats what i want .. i want to know how much a loop run will take in cycles, as various if-else scenarios one iteration of the loop might take differnt amounts of cycles .. then i want to compensate for the various length and padd it up to become a static length to jump to each iterations start Aug 17 14:01:29 if you want predictable timing, use assembly. the time any piece of C code takes will depend on the code itself, possibly other code in the file, the compiler version, the compiler settings, and probably the lunar phase Aug 17 14:01:48 but as we say here , there are many way to rome, so i should be able to make use of your ecap too ... initially i wanted to lear about how to save r4 from this statement into a c-var; LBCO r4, C28, 0xC, 4 Aug 17 14:01:55 so you want to compensate for that, measure the timing dynamically at runtime Aug 17 14:02:01 yes Aug 17 14:02:05 and padd wit nops Aug 17 14:02:31 so my start of the loop always is on the same timing Aug 17 14:02:49 and then you update the compiler and your code will break Aug 17 14:02:53 don't do that Aug 17 14:03:12 why will it break Aug 17 14:03:44 because you have no control over what assembly the compiler will produce from your C code Aug 17 14:04:01 it can and does vary from version to version Aug 17 14:04:13 (along with varying depending on compiler settings) Aug 17 14:04:27 so the timings will vary as well Aug 17 14:04:27 let me rephrase my problem Aug 17 14:05:27 if you want more-or-less fixed timing per loop iteration and want to use C code, then use a timer to make each loop iteration take roughly the same amount of time Aug 17 14:05:35 in a loop , the thirst thing i do is bitbang a spi to clock out some data from a adc , after the in the same iteration of the loop i evaluate,,, do stuff with the data ... that might take X cycle to come back to the next iteration and reclock more data Aug 17 14:05:39 you can use a drift-free timer to make any variation average out Aug 17 14:06:45 so by getting to know how long THIS cycle took and padding nop to match the a static looping .. i thought i can rape this cylce counter Aug 17 14:06:53 (the examples I've given are drift-free) Aug 17 14:07:28 ride on ! i will be a good padavan .. thx alot for the pro brain of yours ! Aug 17 14:07:42 line 16 of https://pastebin.com/5LW2ypX8 is effectively "padding nops" to make each loop iteration take the same amount of time Aug 17 14:08:28 as i said, many ways to rome .. so i will go that ecap route .. looks better then the hacky asm from my example anyway Aug 17 14:09:21 the asm isn't "hacky", it's just asm... the asm generated from this C code looks very similar Aug 17 14:09:30 anyway .. can you hint me on how to save r4 into a c-var ? just for my peace of mind Aug 17 14:09:36 that question doesn't make sense Aug 17 14:09:45 sorry for "hacky" .. asm is still not common for me Aug 17 14:09:54 if you're writing C code, you have no control over register use Aug 17 14:10:01 r4 is owned by the compiler, not by you Aug 17 14:10:13 ok Aug 17 14:10:18 the right question is just "what's the C equivalent to this assembly code?" Aug 17 14:10:44 i hear u ! well spoken ! Aug 17 14:11:06 I'd need to check, it'll look very similar to the eCAP code Aug 17 14:11:19 thx zmatt thx ... i sure hope i get a chance for some real world thankyous at one point to you Aug 17 14:12:46 if you #include "pru_ctrl.h" then the pru cycle counter can be accessed as PRU0_CTRL.CYCLE (for pru core 0) or PRU1_CTRL.CYCLE (for pru core 1) Aug 17 14:17:07 rob_w: so the cycle counter would be something like https://pastebin.com/YTh3b8Jk Aug 17 14:18:01 :-) wow .. thx Aug 17 14:19:03 this doesn't use control register c28 like the assembly does, which would be more efficient but requires more complication in C Aug 17 14:19:14 *constant register c28 Aug 17 14:21:22 spout: oh I just noticed that earlier I accidently addressed rob_w instead of you while I was in fact replying to you: 14:45 <@zmatt> rob_w: I guess this particular dhcp client has experienced feature-bloat and is sort of a network manager on its own :P Aug 17 14:22:54 rob_w: anyway, bit-banging spi sounds like something that requires pretty tight and deterministic timing as well as good performance, so maybe you should consider dipping your toes into assembly :) Aug 17 14:23:08 because in my experience, the code produced by the C compiler is pretty shit Aug 17 14:24:13 i am dipping.. but i need to use the tools i ve ( c mainly) in order to go on ... i got a pretty tight thing going already, with dma to arm etc etc so this cycle count thing was just the last tune i imagined Aug 17 14:30:56 dma to arm? Aug 17 14:38:40 I can imagine use for using dma to transfer data from arm to pru, but I don't see any use for it for transferring data from pru to arm Aug 17 14:38:58 since pru can write to ddr3 memory (where arm can read it) just as fast as it can write to its own local memory Aug 17 14:39:32 (and much faster than EDMA can read from pru memory) Aug 17 14:39:43 maybe I'm misunderstanding what you mean Aug 17 15:36:49 hi all - are there any other images other than the April 22 SD card images? neither work on my BBAI64. Aug 17 15:37:40 the OS image crashes at boot then restarts about 16-20 seconds in, and the flasher image complaines over the console that a partition is missing on mmc (which is there, but that's also the uSD card) Aug 17 15:45:00 sorry june images, just found hte january ones Aug 17 15:55:58 :-/ the Jan image fails to boot and restarts - errors around remotproc16 and looks like it's trying to do something with an R5F but not happy Aug 17 16:09:54 mayab: latest snapshots are here: https://forum.beagleboard.org/t/debian-11-x-bullseye-monthly-snapshots-arm64/32318 Aug 17 16:10:06 Hi @mayab the issue your facing is the version of u-boot installed on the eMMC is broken for newer images.. that's why the u-boot directions are here.. https://beagleboard.org/update-ai64/ Aug 17 16:10:38 for a newer flasher... hold reset and boot buttons, insert power, let off reset, wait for an led to light, then lift off boot... this will guarentee the microSD is used.. Aug 17 16:11:05 @rcn-ee thanks! Aug 17 16:11:33 though I've noticed if I have a bootable SD card in regardless of buttons pressed, it tries to boot off of that - or is that part of hte issue @zmatt mentioned? Aug 17 16:11:42 @zmatt thanks - missed that somehow ... Aug 17 16:11:58 I didn't mention an issue? Aug 17 16:11:59 on the bbai64, eMMC is always first.. Aug 17 16:12:24 the issue, is what we tired to stick in boot0... then when booting the r5 firmware doesn't match and it get stuck.. Aug 17 16:13:06 zmatt: sorry misread all the responses at once - thanks for the latest links Aug 17 16:15:17 @rcn-ee only just got my console cable working, but when there's a bootable sd card present, it never makes it to the pre-flashed eMMC image Aug 17 16:16:14 https://www.irccloud.com/pastebin/MPP5TvOY/ Aug 17 16:16:35 mayab: sudo /opt/u-boot/bb-u-boot-beagleboneai64/install-emmc.sh Aug 17 16:16:35 sudo /opt/u-boot/bb-u-boot-beagleboneai64/install-microsd.sh Aug 17 16:16:35 sudo reboot Aug 17 16:16:56 I installed to eMMC and rebooted - skipped sd cor now - should hate make a difference? Aug 17 16:17:55 https://www.irccloud.com/pastebin/sR5NA8zB/ Aug 17 16:18:04 mayab: too old!.. Aug 17 16:18:42 mayab: just grab this image.. and flash it to a microsd: https://rcn-ee.net/rootfs/debian-arm64-minimal/2022-08-17/bbai64-emmc-flasher-debian-11.4-minimal-arm64-2022-08-17-4gb.img.xz Aug 17 16:19:05 Terrific Llam ? did they misspell Llama or did it get truncated? :P Aug 17 16:19:26 cool - was downloading that as soon as @zmatt sent the link Aug 17 16:19:52 they have funny names. https://github.com/ARM-software/arm-trusted-firmware Aug 17 16:22:35 rcn-ee: I'm not seeing any references to those names there? it looks like it's the DMSC FW, so that would be TI-specific rather than ARM Aug 17 16:22:59 so far so good... Aug 17 16:23:15 did it boot and is it flashing? Aug 17 16:23:32 if I search "Terrific Llama" + arm I just find TI results, e.g. from a baremetal bootlog: "[MCU2_0] 0.000835 s: SCICLIENT: DMSC FW version [19.8.0-v2019.08 (Terrific Llama]" Aug 17 16:23:36 formatting flashing, dd'd some stuff Aug 17 16:23:40 still in prgress Aug 17 16:24:02 rsync'ing /boot/firmware presently Aug 17 16:24:05 zmatt: yeah wrong repo, it should be teh ti DM firmware.. Aug 17 16:25:05 can I propose "Chill Capybara" somewhere? Aug 17 16:25:26 just pin @NishanthMenon . ;) Aug 17 16:27:53 (to evoke the mental image of https://en.wikipedia.org/wiki/File:Capybara_Ueno_Zoo_2009.ogv ) Aug 17 16:30:46 yay! thanks! shiny new system installed Aug 17 16:31:00 \o\ /o/ Aug 17 16:31:07 now to hurt my brain with all the things this thing can do :D Aug 17 16:31:55 mayab: the TDA4VM technical reference manual is a mere 18155 pages ;) Aug 17 16:32:10 a few chapters are still missing though Aug 17 16:32:17 yea i've only flipped through a few chapters of the first volume so far Aug 17 16:32:21 oh? Aug 17 16:33:47 or maybe that's been fixed... I just noticed I don't have the latest revision of the TRM Aug 17 16:35:06 there are r5f and pru examples listed in the forums - i'll start with those :D Aug 17 16:41:38 oh interesting, in rev C they moved all the registers into separate PDFs... Aug 17 16:42:03 yea there's a base pdf and 4 or 5 register ones iirc Aug 17 16:43:27 hm, a bit disappointing that rev B had placeholder chapters "6.12 Hardware Accelerator (HWA) Thread Scheduler (HTS)" and "6.13 Load Store Engine (LSE)" containing just the notice "This section is under development and is included as a placeholder for future updates." Aug 17 16:43:41 but rev C removed these chapters entirely instead of filling them in Aug 17 16:44:07 oh Aug 17 16:45:14 and chapter 13 (which was also a placeholder in rev B) is a two-page joke in rev C Aug 17 16:52:17 oh yea - so ... where's the andendum Aug 17 16:53:01 what wasd 6.11? Aug 17 16:54:02 oh wtf they removed PRUSS from the TRM Aug 17 16:54:17 (which used to be 6.6) Aug 17 17:01:25 WAT Aug 17 17:01:37 k Aug 17 18:02:04 zmatt: version names: it used to be a combination of https://preshing.com/20110811/xkcd-password-generator/ Aug 17 18:50:51 heh Aug 17 21:06:27 hello, I've implemented a gpio mapping with sysfs using the baglebone AI-64. I've been able to read and write pins using my application logic. I've noticed some pins share a common name in gpiofind e.g. P8_35A and P8_35B, but I can't find any good documentation on why this is or what the two modes signify. Aug 17 21:06:47 I've ignored most of the "_B" modes, but wanted further clairfication. Aug 17 21:09:27 probably two cpu pins that connect to the same expansion header pin Aug 17 21:09:35 to provide more functionality options for each pin Aug 17 21:10:39 yep, indeed Aug 17 21:18:21 P8_35 connects to balls AD23 and Y3 of the TDA4VM (via 0Ω resistors R220 and R67 respectively), hence those two pins (and their corresponding gpios) are called P8_35A and P8_35B Aug 17 21:18:50 if you're just using them in gpio mode then ignoring one of them is indeed the correct thing to do **** ENDING LOGGING AT Thu Aug 18 02:59:57 2022