06:36 <Guest42> Hi, I'm trying to set up PRU system to toggle a 12 MHz clock, and am really struggling to get anything to work. The closest I've gotten was using libpruio for their examples, but I can't get them to run correctly. I get an error when running the pruss_toggle example: "initialisation failed (parsing kernel claims)." How would I troubleshoot this to

06:36 <Guest42> figure out how to get the example working, what is meant by an error when "parsing kernel claims"?

06:39 <Guest42> In the long run, I would like to setup something that can output and read from 20 or so I/O pins, and then there is a clock that needs to run at 12 MHz. The purpose of this is to interface with this chip: http://www.holtic.com/products/2981-hi-1575.aspx to control the inputs and process the output, my thinking is that the pru is the best option for

06:39 <Guest42> this, but I am open to any suggestions from a more experienced user

06:41 <zmatt> note that if you want to use pru for a custom purpose then libpruio isn't of any particular use

06:42 <zmatt> it's just some generic I/O library that uses PRU for some stuff

06:42 <zmatt> (I don't know much about how libpruio works so I have no idea what it could possibly mean by "initialisation failed (parsing kernel claims).")

06:44 <zmatt> the beaglebone has pins that can output a configurable clock (e.g. pwm pins) so you don't really need PRU for that, but let me check the datasheet of this chip to have an idea what you're trying to do

06:44 <Guest42> Yea, I was thinking I could just use it to control the pins, and according to others it is easy to use, but I've been struggling with it anyway

06:45 <Guest42> Can the pwm pins output at 12 mhz?

06:46 <zmatt> I've never used libpruio myself. I do know PRU pretty well, I've actually written a python library that can load code onto PRU and interact with it via shared memory and/or interrupts: https://github.com/mvduin/py-uio

06:48 <Guest42> I can definitely try that. I am interested in how you say about using the pwm, if that is any easier to use than the pru I would be more inclined to go that route

06:49 <zmatt> depends on the pwm pin... the eCAP/eHRPWM pins can't produce an exact 12 MHz (the closest for them would be 12.5 MHz) but the timer pins do have that ability, and there's also a configurable clock output pin that I *think* can produce 12 MHz though I'd need to check

06:52 <zmatt> for some reason the timer pins aren't setup for pwm by default so a bit of fiddling is needed regardless

06:57 <zmatt> it looks like the communication with the chip you linked isn't very time-sensitive, depending a bit on how fast you want to be able to perform transfers on this bus

06:58 <zmatt> so there's a bunch of options on how to approach that, with different trade-offs for performance vs complexity

06:58 <zmatt> (with pru obviously being the highest performance option)

07:00 <Guest42> Yes, the time is fairly ok as far as I see, the bus is limited to 1 Mbps and it takes in 16 bit data, so I only need 60 kHz of "speed" as far as I know. As far as complexity, what is the simplest way I might be able to achieve that for the purpose of getting something working?

07:02 <zmatt> the simplest, and lowest performance, option is to just use gpio for the entire bus interface, controlled from linux userspace via sysfs (or via gpiod if that's your thing)

07:03 <zmatt> that just leaves the 12 MHz clock question, let me see if I can figure that one out

07:08 <zmatt> another interesting option would be to use lcdc via py-uio as bus interface controller... it can directly perform the bus interface protocol

07:09 <zmatt> though that wouldn't allow the SYNC pin to be captured during reads, but I can't tell if that's a problem or not

07:09 <Guest42> The sync pin is necessary to read

07:11 <Guest42> well, I suppose it could be worked around by reading RSYNCA from the status and mode register after every read

07:16 <zmatt> (I'm still checking stuff)

07:17 <Guest42> All good, I appreciate you taking your time!

07:27 <zmatt> Guest746: to illustrate the benefit of the lcdc approach, after the appropriate setup is done it would be this simple to do bus access: https://pastebin.com/ggy6FEAu (two variants given depending on the wiring used)

07:29 <zmatt> (for transmit it would be possible to control the sync pin as a gpio, drive it low/high before writing the transmit word and set it back to high-Z before doing a read)

07:30 <zmatt> (or as you said, use SAM)

07:30 <zmatt> so even with the overhead of reading SAM after every read it might be worth it

07:31 <zmatt> I don't think you'd manage to read 60 kwords/s using sysfs gpio

07:32 <zmatt> anyway, let me finish writing an overlay for enabling a timer pin as pwm output... I'm not sure why I've never made an example for that yet, it has certainly come up before

07:33 <jfsimon1981_b> Good morning

07:49 <zmatt> oh he left, I guess he'll be back eventually

08:18 <zmatt> oh, standard overlays for the timer pwm outputs do exist... it's just not part of cape-universal for some reaosn

21:42 <set_> What is the "org" on line 16 at this page online: https://docs.beagleboard.org/latest/books/pru-cookbook/03details/details.html#id31 ?

21:43 <set_> I see the "org" on many lines but I have no clue on how to look up the def.

21:53 <set_> I mean...is it just a object to put addresses in via assignment?

21:54 <set_> So, could "org" be any assigned text?

21:56 <set_> Anyway, the docs. are nice. I will keep learning from them!

22:07 <jfsimon1981_b> hi set_

22:07 <jfsimon1981_b> seems like a position index

22:08 <jfsimon1981_b> Either register position or ROM positions, something similar.

22:08 <jfsimon1981_b> Apparently an address.

22:12 <set_> Right. I see the address gets assigned to the "org" place holder.

22:13 <set_> But...I guess I am just unfamiliar w/ how assigning so many addresses to the same place holder can be useful.

22:53 <set_> or...is it assembly since it is a linker file?

22:57 <zmatt> it's a linker script... arcane stuff you generally don't need to mess with

22:59 <zmatt> anyway, zZ

23:00 <Guest66> Hello, I have got a problem, I changed Uenv.txt in basic embedded BeagleBone ai kernel, so now I have 4 Leds flashed and my PC does not see the board. I tried to boot via SD with debian image and I have only  D2 Led flashed. Do you know how to reset embedded kernel

23:00 <Guest66> Or to fix it

23:01 <zmatt> bbai or bbai64 ?

23:01 <Guest66> ai

23:02 <zmatt> if you insert a bootable sd card it should boot from sd card

23:02 <zmatt> what image did you flash onto the sd card?

23:02 <Guest66> D2 is flashing

23:02 <Guest66> And how check embedded debian

23:02 <Guest66> without SD card 4 leds flashes

23:03 <Guest66> fix

23:03 <Guest66> I meant fix embedded debian

23:03 <Guest66> fix Uenv.txt there

23:04 <Guest66> Or reset

23:04 <zmatt> 00:02 <@zmatt> what image did you flash onto the sd card?

23:07 <zmatt> ok, not answering is fine too, I was heading to bed anyway. afk, zZ

23:07 <Guest66> am57xx-debian-10.3-iot-tidl-armhf-2020-04-06-6gb

23:09 <set_> Okay. No issue.

23:10 <Guest66> Yes, but I can not boot basic embedded images, because I changed Uenv.txt there

23:10 <Guest66> And I am thinking of to to change it again

23:10 <Guest66> But I can not connect via ssh

23:11 <Guest66> and 4 leds flasheds without sd card

23:12 <Guest66> With sd card one led flashes

23:12 <Guest66> D2

23:14 <Guest66> So does anyone knows how to fix it?

23:15 <Guest66> Don't want to turn beaglebone into a rick

23:15 <Guest66> brick

23:19 <Guest66> How to repair basic kernel

23:19 <Guest66> if Uenv.txt changed

23:20 <Guest66> I unncomented the line that is used t unlock eMMC

23:41 <set_> Guest66: Do you have a Linux computer?

23:42 <zmatt> pff, sleep failed

23:43 <zmatt> Guest66: you mean the line that turns a system into a flasher? yeah doing that on your eMMC will certainly make it not boot. however on the bbai this shouldn't have any effect on being able to boot from sd card

23:43 <zmatt> did you use Etcher to flash the image to sd card?

23:44 <zmatt> wait, "With sd card one led flashes" ... you mean in a heartbeat-pattern? because that sounds to me like you booted successfully from sd card

23:48 <set_> @zmatt cannot sleep!

23:50 <zmatt> Guest66: once booted from sd card you could mount the emmc and fix /boot/uEnv.txt on it to make it bootable from eMMC again.... or you could just reflash eMMC by either turning your sd card into an eMMC-flasher by uncommenting one line in /boot/uEnv.txt on the sd card (the cmdline=init=/opt/scripts/tools/eMMC/init-eMMC-flasher-v3.sh line at the bottom of the file), or you could download a pre-made ...

23:50 <zmatt> ...emmc flasher image and flash ...

23:50 <zmatt> ... that onto sd card and boot the beaglebone from that

23:51 <set_> bugged?

23:51 <zmatt> more like there's two separate mechanisms splitting my chat line with different thresholds

23:52 <set_> hmm

23:52 <set_> beats me

23:52 <zmatt> Guest66: anyway, regardless your beaglebone is not bricked, it's just currently failing to boot from emmc (because you mucked up its /boot/uEnv.txt file)

23:53 <zmatt> but that's always fixable

23:56 <set_> fix it!

23:56 <zmatt> k, gonna give sleep another try

23:56 <zmatt> afk

23:56 <set_> no!