**** BEGIN LOGGING AT Sun Nov 06 02:59:56 2022 Nov 06 06:36:11 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 Nov 06 06:36:11 figure out how to get the example working, what is meant by an error when "parsing kernel claims"? Nov 06 06:39:30 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 Nov 06 06:39:31 this, but I am open to any suggestions from a more experienced user Nov 06 06:41:37 note that if you want to use pru for a custom purpose then libpruio isn't of any particular use Nov 06 06:42:12 it's just some generic I/O library that uses PRU for some stuff Nov 06 06:42:44 (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).") Nov 06 06:44:22 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 Nov 06 06:44:41 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 Nov 06 06:45:22 Can the pwm pins output at 12 mhz? Nov 06 06:46:12 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 Nov 06 06:48:50 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 Nov 06 06:49:19 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 Nov 06 06:52:31 for some reason the timer pins aren't setup for pwm by default so a bit of fiddling is needed regardless Nov 06 06:57:37 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 Nov 06 06:58:10 so there's a bunch of options on how to approach that, with different trade-offs for performance vs complexity Nov 06 06:58:48 (with pru obviously being the highest performance option) Nov 06 07:00:45 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? Nov 06 07:02:52 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) Nov 06 07:03:18 that just leaves the 12 MHz clock question, let me see if I can figure that one out Nov 06 07:08:26 another interesting option would be to use lcdc via py-uio as bus interface controller... it can directly perform the bus interface protocol Nov 06 07:09:11 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 Nov 06 07:09:49 The sync pin is necessary to read Nov 06 07:11:35 well, I suppose it could be worked around by reading RSYNCA from the status and mode register after every read Nov 06 07:16:40 (I'm still checking stuff) Nov 06 07:17:01 All good, I appreciate you taking your time! Nov 06 07:27:48 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) Nov 06 07:29:24 (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) Nov 06 07:30:14 (or as you said, use SAM) Nov 06 07:30:49 so even with the overhead of reading SAM after every read it might be worth it Nov 06 07:31:40 I don't think you'd manage to read 60 kwords/s using sysfs gpio Nov 06 07:32:42 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 Nov 06 07:33:30 Good morning Nov 06 07:49:43 oh he left, I guess he'll be back eventually Nov 06 08:18:35 oh, standard overlays for the timer pwm outputs do exist... it's just not part of cape-universal for some reaosn Nov 06 21:42:27 What is the "org" on line 16 at this page online: https://docs.beagleboard.org/latest/books/pru-cookbook/03details/details.html#id31 ? Nov 06 21:43:26 I see the "org" on many lines but I have no clue on how to look up the def. Nov 06 21:53:31 I mean...is it just a object to put addresses in via assignment? Nov 06 21:54:48 So, could "org" be any assigned text? Nov 06 21:56:23 Anyway, the docs. are nice. I will keep learning from them! Nov 06 22:07:45 hi set_ Nov 06 22:07:53 seems like a position index Nov 06 22:08:14 Either register position or ROM positions, something similar. Nov 06 22:08:54 Apparently an address. Nov 06 22:12:17 Right. I see the address gets assigned to the "org" place holder. Nov 06 22:13:08 But...I guess I am just unfamiliar w/ how assigning so many addresses to the same place holder can be useful. Nov 06 22:13:18 * set_ needs to learn more I guess? Nov 06 22:53:53 or...is it assembly since it is a linker file? Nov 06 22:57:27 it's a linker script... arcane stuff you generally don't need to mess with Nov 06 22:59:32 anyway, zZ Nov 06 23:00:39 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 Nov 06 23:00:57 Or to fix it Nov 06 23:01:29 bbai or bbai64 ? Nov 06 23:01:34 ai Nov 06 23:02:05 if you insert a bootable sd card it should boot from sd card Nov 06 23:02:10 what image did you flash onto the sd card? Nov 06 23:02:16 D2 is flashing Nov 06 23:02:34 And how check embedded debian Nov 06 23:02:51 without SD card 4 leds flashes Nov 06 23:03:15 fix Nov 06 23:03:23 I meant fix embedded debian Nov 06 23:03:39 fix Uenv.txt there Nov 06 23:04:06 Or reset Nov 06 23:04:18 00:02 <@zmatt> what image did you flash onto the sd card? Nov 06 23:07:08 ok, not answering is fine too, I was heading to bed anyway. afk, zZ Nov 06 23:07:24 am57xx-debian-10.3-iot-tidl-armhf-2020-04-06-6gb Nov 06 23:09:07 Okay. No issue. Nov 06 23:10:18 Yes, but I can not boot basic embedded images, because I changed Uenv.txt there Nov 06 23:10:33 And I am thinking of to to change it again Nov 06 23:10:55 But I can not connect via ssh Nov 06 23:11:07 and 4 leds flasheds without sd card Nov 06 23:12:22 With sd card one led flashes Nov 06 23:12:24 D2 Nov 06 23:14:57 So does anyone knows how to fix it? Nov 06 23:15:15 Don't want to turn beaglebone into a rick Nov 06 23:15:19 brick Nov 06 23:19:20 How to repair basic kernel Nov 06 23:19:31 if Uenv.txt changed Nov 06 23:20:01 I unncomented the line that is used t unlock eMMC Nov 06 23:41:10 Guest66: Do you have a Linux computer? Nov 06 23:42:16 pff, sleep failed Nov 06 23:43:00 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 Nov 06 23:43:14 did you use Etcher to flash the image to sd card? Nov 06 23:44:45 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 Nov 06 23:48:07 @zmatt cannot sleep! Nov 06 23:50:39 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 ... Nov 06 23:50:45 ...emmc flasher image and flash ... Nov 06 23:50:47 ... that onto sd card and boot the beaglebone from that Nov 06 23:51:21 * zmatt . o O ( huh, why did my chatline get broken into three pieces like that, that's weird ) Nov 06 23:51:40 bugged? Nov 06 23:51:58 more like there's two separate mechanisms splitting my chat line with different thresholds Nov 06 23:52:05 hmm Nov 06 23:52:33 beats me Nov 06 23:52:56 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) Nov 06 23:53:05 but that's always fixable Nov 06 23:56:07 fix it! Nov 06 23:56:39 k, gonna give sleep another try Nov 06 23:56:42 afk Nov 06 23:56:44 no! Nov 07 00:07:25 Fine. Nov 07 00:07:35 I worked through it. **** ENDING LOGGING AT Mon Nov 07 02:59:56 2022