<zmatt>
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)
<zmatt>
e.g. if you want to make timers, I'd suggest using eCAP or IEP
<zmatt>
I think I have example C code for that somewhere...
<zmatt>
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
<rob_w>
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
<rob_w>
i read the i can reset the counter and restart it every loop ..
<rob_w>
what would be those intrincsics zmatt ?
spout has joined #beagle
<spout>
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...
<spout>
zmatt Thank you for the solution :-)
<zmatt>
spout: generally my solution for solving networking issues is just removing connman and every other network manager package and use systemd-networkd instead ;)
<spout>
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 ?
<zmatt>
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
<spout>
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 :-)
<zmatt>
(debian bullseye images already use systemd-networkd)
<zmatt>
of course you can use any network manager you want, it's just a debian system
<spout>
systemd-networkd works with dhcpcd ?
<zmatt>
I have no idea what dhcpcd is, systemd-networkd does dhcp itself
<spout>
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
<spout>
i tought it was linked to a package named dhcpcd5 ?
<zmatt>
uhh, that doesn't make sense... if you're using manual network configuration, why would you be using a dhcp client?
<zmatt>
the point of dhcp is _not_ having to configure any of those things
<zmatt>
(i.e. just plug it into the network and have it work)
<spout>
ok, I think I'm a little lost and confused by the roles of dhcp client, network manager, etc.:-O
<zmatt>
a network manager is the general term of a piece of software that manages your network interfaces
<zmatt>
it will generally either embed a dhcp client or invoke an external one
<zmatt>
dhcp is the protocol used to obtain an ip and network settings from the router on your network
<zmatt>
avoiding the need for manual ip configuration
<zmatt>
systemd-networkd and connman are examples of network manager
<zmatt>
s
<spout>
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 ?
<rob_w>
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 ?
<spout>
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" ?
<zmatt>
rob_w: example how you might use my eCAP example to call something periodically in a loop: https://pastebin.com/5LW2ypX8
<zmatt>
rob_w: I guess this particular dhcp client has experienced feature-bloat and is sort of a network manager on its own :P
<zmatt>
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
<zmatt>
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
<zmatt>
the cycle counter is really just meant for performance profiling by a debugger
<zmatt>
not for general purpose timers
<rob_w>
ok i hear u
<rob_w>
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
<zmatt>
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
<rob_w>
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
<zmatt>
so you want to compensate for that, measure the timing dynamically at runtime
<rob_w>
yes
<rob_w>
and padd wit nops
<rob_w>
so my start of the loop always is on the same timing
<zmatt>
and then you update the compiler and your code will break
<zmatt>
don't do that
<rob_w>
why will it break
<zmatt>
because you have no control over what assembly the compiler will produce from your C code
<zmatt>
it can and does vary from version to version
<zmatt>
(along with varying depending on compiler settings)
<zmatt>
so the timings will vary as well
<rob_w>
let me rephrase my problem
<zmatt>
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
<rob_w>
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
<zmatt>
you can use a drift-free timer to make any variation average out
ikarso has joined #beagle
<rob_w>
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
<zmatt>
(the examples I've given are drift-free)
<rob_w>
ride on ! i will be a good padavan .. thx alot for the pro brain of yours !
<zmatt>
line 16 of https://pastebin.com/5LW2ypX8 is effectively "padding nops" to make each loop iteration take the same amount of time
<rob_w>
as i said, many ways to rome .. so i will go that ecap route .. looks better then the hacky asm from my example anyway
<zmatt>
the asm isn't "hacky", it's just asm... the asm generated from this C code looks very similar
<rob_w>
anyway .. can you hint me on how to save r4 into a c-var ? just for my peace of mind
<zmatt>
that question doesn't make sense
<rob_w>
sorry for "hacky" .. asm is still not common for me
<zmatt>
if you're writing C code, you have no control over register use
<zmatt>
r4 is owned by the compiler, not by you
<rob_w>
ok
<zmatt>
the right question is just "what's the C equivalent to this assembly code?"
<rob_w>
i hear u ! well spoken !
<zmatt>
I'd need to check, it'll look very similar to the eCAP code
<rob_w>
thx zmatt thx ... i sure hope i get a chance for some real world thankyous at one point to you
brook has joined #beagle
<zmatt>
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)
<zmatt>
this doesn't use control register c28 like the assembly does, which would be more efficient but requires more complication in C
<zmatt>
*constant register c28
<zmatt>
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
otisolsen70 has quit [Ping timeout: 248 seconds]
<zmatt>
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 :)
<zmatt>
because in my experience, the code produced by the C compiler is pretty shit
<rob_w>
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
<zmatt>
dma to arm?
<zmatt>
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
<zmatt>
since pru can write to ddr3 memory (where arm can read it) just as fast as it can write to its own local memory
<zmatt>
(and much faster than EDMA can read from pru memory)
<zmatt>
maybe I'm misunderstanding what you mean
rob_w has quit [Remote host closed the connection]
spout has quit [Quit: Client closed]
brook has quit [Remote host closed the connection]
mayab has joined #beagle
brook has joined #beagle
brook has quit [Ping timeout: 256 seconds]
<mayab>
hi all - are there any other images other than the April 22 SD card images? neither work on my BBAI64.
<mayab>
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)
<mayab>
sorry june images, just found hte january ones
brook has joined #beagle
<mayab>
:-/ 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
<rcn-ee>
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/
<rcn-ee>
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..
<mayab>
@rcn-ee thanks!
<mayab>
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?
<mayab>
@zmatt thanks - missed that somehow ...
<zmatt>
I didn't mention an issue?
<rcn-ee>
on the bbai64, eMMC is always first..
<rcn-ee>
the issue, is what we tired to stick in boot0... then when booting the r5 firmware doesn't match and it get stuck..
<mayab>
zmatt: sorry misread all the responses at once - thanks for the latest links
<mayab>
@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
<zmatt>
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
<mayab>
so far so good...
<rcn-ee>
did it boot and is it flashing?
<zmatt>
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]"
<mayab>
formatting flashing, dd'd some stuff
<mayab>
still in prgress
<mayab>
rsync'ing /boot/firmware presently
<rcn-ee>
zmatt: yeah wrong repo, it should be teh ti DM firmware..
<mayab>
now to hurt my brain with all the things this thing can do :D
<zmatt>
mayab: the TDA4VM technical reference manual is a mere 18155 pages ;)
<zmatt>
a few chapters are still missing though
<mayab>
yea i've only flipped through a few chapters of the first volume so far
<mayab>
oh?
<zmatt>
or maybe that's been fixed... I just noticed I don't have the latest revision of the TRM
jfsimon1981 has joined #beagle
<mayab>
there are r5f and pru examples listed in the forums - i'll start with those :D
<zmatt>
oh interesting, in rev C they moved all the registers into separate PDFs...
<mayab>
yea there's a base pdf and 4 or 5 register ones iirc
ikarso has quit [Quit: Connection closed for inactivity]
xet7 has quit [Ping timeout: 268 seconds]
<zmatt>
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."
<zmatt>
but rev C removed these chapters entirely instead of filling them in
<mayab>
oh
<zmatt>
and chapter 13 (which was also a placeholder in rev B) is a two-page joke in rev C
otisolsen70_ has quit [Remote host closed the connection]
otisolsen70__ has quit [Ping timeout: 248 seconds]
<randombot>
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.
<randombot>
I've ignored most of the "_B" modes, but wanted further clairfication.
<zmatt>
probably two cpu pins that connect to the same expansion header pin
<zmatt>
to provide more functionality options for each pin
<zmatt>
yep, indeed
<zmatt>
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
<zmatt>
if you're just using them in gpio mode then ignoring one of them is indeed the correct thing to do
akaWolf has quit [Ping timeout: 268 seconds]
otisolsen70 has joined #beagle
starblue has quit [Ping timeout: 256 seconds]
akaWolf has joined #beagle
starblue has joined #beagle
lucascastro has quit [Ping timeout: 256 seconds]
otisolsen70 has quit [Quit: Leaving]
randombot has quit [Remote host closed the connection]
randombot has joined #beagle
randombot has quit [Remote host closed the connection]