<set_> ...for the Native_SDK from Imag. Tech. for the SGX, there are plenty of libs. needed to build the SDK too. So, be prepared!
<set_> Oh.
<set_> For the Native_SDK and complete build process, one would need an updated version of cmake (3.16 at least). On kernel 5.4.x, only 3.13 resides. Time to upgrade.
<set_> do not cat every dir. in /usr/bin/c*. Ha.
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #beagle
_whitelogger has joined #beagle
buzzmarshall has quit [Ping timeout: 240 seconds]
buzzmarshall has joined #beagle
ikarso has joined #beagle
Shadyman has quit [Ping timeout: 268 seconds]
Shadyman has joined #beagle
Shadyman has quit [Ping timeout: 260 seconds]
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Shadyman has joined #beagle
blech has quit [Ping timeout: 268 seconds]
blech has joined #beagle
giort has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
giort has quit [Ping timeout: 265 seconds]
otisolsen70 has joined #beagle
_Posterdati_ has joined #beagle
Posterdati has quit [Ping timeout: 245 seconds]
<mvaittin> Anyone tried the vanilla kernel v5.15-rc1 on beaglebone black? Mine fails to boot. The v5.14 booted Ok. Any changes known to break things with old uBoot or configs?
<mvaittin> (kernel configs)
<mvaittin> Last thing I see in serial logs is loading the kernel and device-tree from tftp-server && the booting kernel print. Nothing after that.
Shadyman has quit [Quit: Leaving.]
florian has joined #beagle
starblue1 has quit [Ping timeout: 252 seconds]
set_ has quit [Quit: I thought I saw a puddy-cat...]
ikarso has quit [Quit: Connection closed for inactivity]
set_ has joined #beagle
otisolsen70 has quit [Quit: Leaving]
johanhenselmans has joined #beagle
johanhenselmans has quit [Client Quit]
starblue1 has joined #beagle
nerdboy has quit [Ping timeout: 265 seconds]
nerdboy has joined #beagle
nerdboy has quit [Changing host]
nerdboy has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
otisolsen70 has joined #beagle
ikarso has joined #beagle
vd has quit [Quit: Client closed]
vd has joined #beagle
buzzmarshall has quit [Quit: Konversation terminated!]
buzzmarshall has joined #beagle
M-blaise has joined #beagle
M-blaise has quit [Ping timeout: 252 seconds]
M-blaise has joined #beagle
starblue1 has quit [Ping timeout: 252 seconds]
starblue1 has joined #beagle
M-blaise has quit [Ping timeout: 252 seconds]
charlie5 has joined #beagle
M-blaise has joined #beagle
vagrantc has joined #beagle
M-blaise has quit [Remote host closed the connection]
M-blaise has joined #beagle
M-blaise has quit [Ping timeout: 265 seconds]
M-blaise has joined #beagle
nerdboy has quit [Ping timeout: 260 seconds]
M-blaise has quit [Ping timeout: 240 seconds]
waldo323 has joined #beagle
M-blaise has joined #beagle
_Posterdati_ has quit [Ping timeout: 268 seconds]
ikarso has quit [Quit: Connection closed for inactivity]
_Posterdati_ has joined #beagle
M-blaise has quit [Ping timeout: 252 seconds]
_Posterdati_ has quit [Excess Flood]
M-blaise has joined #beagle
nerdboy has joined #beagle
nerdboy has joined #beagle
nerdboy has quit [Changing host]
giort has joined #beagle
giort has quit [Ping timeout: 252 seconds]
Guest5953 has joined #beagle
Guest5953 has quit [Client Quit]
the_person48 has joined #beagle
<the_person48> hey guys, I am running debian 9.5, kernel 4.14.108-ti-r36, on a beaglebone black rev C. I am trying to figure out how to change the boot configuration of the GPIO pins using boot overlays. I followed the instructions here: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/compiling-an-overlay
<the_person48> was able to compile the file successfully on my host computer, then moved the compiled .dtbo file to /lib/firmware
giort has joined #beagle
florian has quit [Quit: Ex-Chat]
<the_person48> modified the /boot/uEnv.txt file so that "enable_uboot_overlays=1" is uncommented, and all the override capes lines are commented except for one I added under custom cape:
<the_person48> dtb_overlay=/lib/firmware/test_dtbo_overlay.dtbo
<the_person48> then I downloaded the show-pins utility to verify whether or not it's working. I looked at P9.17, because the example I downloaded I believe is supposed to modify that one's configuration:
<the_person48> 0x150 0x30 /* spi0_sclk, INPUT_PULLUP | MODE0 */
<the_person48> (I think 0x150 is the P9.17)
<the_person48> I'm not sure exactly what to set the second hex value to, I tried 0x10, 0x20, 0x70, and compared the show-pins output of P9.17 in each case, but don't see a difference. Recompiled/adjusted /boot/uEnv.txt and rebooted in between each test
<the_person48> I always get: P9.17 / spi boot cs 87 fast rx up 7 gpio 0.05 << hi P9_17 (pinmux_P9_17_default_pin)
<the_person48> anyone know what I'm doing wrong?
giort has quit [Quit: giort]
giort has joined #beagle
<the_person48> I wasn't able to follow the instructions from the original tutorial on exporting the overlay; I think they're out of date: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay because there is no /sys/devices/bone_capemgr.*/slots directory
<the_person48> so I did the part where I enabled it in the /boot/uEnv.txt thing instead
behanw has joined #beagle
vd has quit [Ping timeout: 256 seconds]
<vagrantc> you're also running a pretty old version of debian ... maybe the instructions are too new?
<the_person48> that's an interesting point
<the_person48> yeah I wanted to run 10 but the people on my project want to run this one cause they've used it succesfully before
<vagrantc> and i would guess debian bullseye (11) should have support for the beaglebone black too...
<the_person48> I think 11 is a little bit too bleeding edge; I tried it the other day and was having a bunch of issues.
<the_person48> but yeah, for now, I'm stuck with 9.5 unless I can show that I can't make it work
<the_person48> any ideas how to do the overlay there?
<vagrantc> sorry, haven't worked much with beagle* lately
<vagrantc> other's might chime in ... wait a while :)
<the_person48> for sure! to summarize for others, having trouble getting boot overlays to work for GPIO pin configurations, on debian 9.5, kernel 4.14.108-ti-r36, mostly following these instructions: https://learn.adafruit.com/introduction-to-the-beaglebone-black-device-tree/exporting-and-unexporting-an-overlay and using show-pins to verify
<rcn-ee> the_person48, do you have a usb-serial adapter plugged into J1? Otherwise u-boot overlays are impossible to debug...
<the_person48> I do not
<rcn-ee> Adafruit's spi overlay is buggy, that was written before we found out spi had bug, all pins need to be input for spi to work..
<the_person48> interesting, what does the usb-serial adapter do for uboot overlays?
<the_person48> gotcha
<the_person48> is there another one that you would suggest instead?
Guilherme has joined #beagle
<rcn-ee> the_person48, it allows you to see this: https://gist.github.com/RobertCNelson/4cf3614923fc92a826dca1f611841c0d
<the_person48> yeah I see how that could be helpful
<the_person48> and you can't get that with just a regular micro-USB to USB cable?
<rcn-ee> the_person48, no... the USB port serial adapter is created by the Linux Gadget driver... so 10seconds "after" the board booted...
<rcn-ee> the_person48, cable options: https://elinux.org/Beagleboard:BeagleBone_Black_Serial
<the_person48> ahhh
<the_person48> ok, so I'll try these two example dts files you linked, then if they work, great, and if not will look into getting this cable for further troubleshooting
<the_person48> ?
<rcn-ee> if all you want is 'spidev', just flash the latest image: https://rcn-ee.net/rootfs/bb.org/testing/2021-09-01/buster-iot/ and set BB-SPIDEV*.dtbo as one of hte overlays
<the_person48> it looks like the links you have are just dts files so I'm guessing you mean for me to use pretty much the same process, just a different file, yeah?
<the_person48> well unfortunately I need to try to make it work on 9.5, at least for now
<the_person48> this is what my coworkers have requested
<the_person48> if I try for a while and show it can't be done or is impratically difficult, then I can argue for a later image
<rcn-ee> the_person48, no, adafruit's dtc directions won't work, we are using a preprocessor.. they are already pre-built, or you can install the "bb-cape-overlays" debian packages
<rcn-ee> the_person48, ps, i'm done with 9.x so no more packages...
<rcn-ee> (that haven't already ben built..)
<the_person48> yeah, that's fine
<the_person48> ok, I'm still a little confused then
<the_person48> so I install the "bb-cape-overlay" package
<rcn-ee> about what?
<the_person48> one of the two you linked
<rcn-ee> sudo apt update ; sudo apt install bb-cape-overlay
<the_person48> and then that provides a separate way of loading the overlays?
<rcn-ee> "it" provides /lib/firmware/*.dtbo
<the_person48> ok, and then I can try loading some of those using /boot/uEnv.txt method?
<rcn-ee> correct..
<the_person48> ok great
<the_person48> will do
<rcn-ee> as long as u-boot isn't ancient..
<the_person48> is there a way to check how old it is?
<rcn-ee> sudo /opt/scripts/tools/version.sh
<the_person48> ok, do you want that whole output?
<the_person48> also, I updated and tried to apt install bb-cape-overlay but it says it can't find the package
<the_person48> maybe I have to clone manually?
<Guilherme> Hey, has anyone had a bit of trouble with remoteproc messages and storing bytes in memory from a register (SBCO)? I am writing 12 bytes (3 times 4 byte SBCOs, offset by 4 bytes each time) to 0x0000 with a 200 byte offset in order to read data obtained through ASM in the C portion of the code, and that seems to make pru_rpmsg_send break on the 9th
<rcn-ee> the_person48, put it on pastebin so you can share it..
<Guilherme> time I do it (times out, "output:id 16 out of range")
<the_person48> here's the output
<rcn-ee> [ 0.975774] pinctrl-single 44e10800.pinmux: pin PIN84 already requested by ocp:P9_22_pinmux; cannot claim for 48030000.spi
giort has quit [Ping timeout: 268 seconds]
<the_person48> so multiple interfering overlays or something like that?
<rcn-ee> the_person48, remove your /boot/uENv.txt dtb_overlay=/lib/firmware/test_dtbo_overlay2.dtbo and run: sudo apt-get update ; sudo apt-get install bb-cape-overlays
<zmatt> the_person48: you need to disable cape-universal's pinmux helper for any pin your overlay uses
<the_person48> ok, and is that done in /boot/uEnv.txt? or in the actual overlay file?
<zmatt> in the overlay
<rcn-ee> his stack is soo old, i don't remember if i backported all the pinremoving...
<rcn-ee> comment out the enable_uboot_cape_universal in /boot/uEnv.txt
<zmatt> my overlay-utils has a nice macro for it: https://github.com/mvduin/overlay-utils/blob/master/i2c1.dtsi#L3-L4
<zmatt> or you can disable cape-universal entirely yeah
<zmatt> (in which case you can't use config-pin and are forced to do all pinmux setup using one or more overlays)
<rcn-ee> the_person48, do you need anything other then spi?
<the_person48> that's ok, I will just disable it for now at least
<the_person48> yeah I need to configure a lot of of the pins. I was just trying to get an example working before I expanded it
<rcn-ee> yeah, then just disable it outright, so you don't have to fight it..
<zmatt> Guilherme: your description is rather vague... where exactly is your assembly code writing stuff? have you made sure that that the compiler knows about this and doesn't use that memory itself?
<the_person48> ok cool, will do
<zmatt> Guilherme: since if you're scribbling onto memory that's used by your C code or any library it uses, then yeah you will break things undoubtedly
<Guilherme> Yea, I tried to condense it as much as possible and missed on some details. I had a guess that could be it as well, I'm writing to the PRU's own DRAM (or at least trying to) at 0x0200, a 200 byte offset to avoid the heap and stack entirely, however, I didn't find much documentation on that at first
<Guilherme> So my belief is that indeed I'm writing to portions of memory that are used by my C code
<zmatt> there's a few ways you can fix this
<Guilherme> However, are there any other slightly more elegant ways to transfer about 16 bytes of data as a message? I could return by writing to r14, but from what I found, that is limited to a single word
<Guilherme> Oh, yea, any way that I could fix this is AOK
<zmatt> transfer from assembly code on the pru to C code on the same pru? the other pru? linux code?
<Guilherme> Oh, from ASM to C code on the same PRU
<zmatt> same way you'd do so from C code to C code, have the caller pass a pointer to the location where the callee should put the data
<the_person48> ok, commenting enable_uboot_cape_universal seems to have worked!
<the_person48> P9.17 is definitely different now
<the_person48> P9.17 / spi boot cs 87 fast up 0 spi 0 cs 0 spi@48030000 (spi0_pins_s0)
<Guilherme> So I could pass a 32 bit pointer through the parameter registers and write to it or would you suggest other way?
<the_person48> here's the new output of /opt/scripts/tools/version.sh: https://pastebin.com/Dc5j9trM
troth has joined #beagle
<rcn-ee> yeap, spi should work now..
<zmatt> Guilherme: I mean, that's the simplest and most obvious way, unless you have very specific reasons to favor an alternate solution
<Guilherme> Yea, I don't remember why I wanted to write to an absolute place in memory in the first place, thanks a ton for the help
<the_person48> still unable to install bb-cape-overlay though; it says E: Unable to locate package bb-cape-overlay
<zmatt> Guilherme: C also supports passing large structs by value, but that actually just uses a pointer behind the scenes
<zmatt> the_person48: bb-cape-overlays I think?
<the_person48> ah that's working
<zmatt> return struct by value I mean
<zmatt> (passing large structs uses the stack)
<zmatt> actually now that I think of it I'm not sure what the C calling conventions are on PRU, I only use assembly for PRU
<Guilherme> I used to stick to ASM as well, but with remoteproc, I had to move some stuff to C to adhere to new standards
<zmatt> remoteproc sucks, it's slow and bloated
<the_person48> ok, so I got bb-cape-overlays installed. Now I'm trying to extend the overlay to set a bunch of the GPIO pins to the modes I want. Is the easiest way to do that just modifying the Adafruit .dts overlay file I already have, or should I be doing something new with the bb-cape-overlays package?
<Guilherme> Yea, I agree, I've lost quite a bit of performance but we're using the new kernel for other stuff, so I'm min-maxing everywhere I can
<zmatt> and any use of it will destroy the deterministic performance that's normally the biggest asset for pru
<zmatt> new kernel? how new?
<Guilherme> by "new" I mean new to us, the TI kernel with Buster (4.19)
<zmatt> 4.19 supports uio-pruss just fine
<zmatt> you can switch between remoteproc-pru and uio-pruss in /boot/uEnv.txt
<Guilherme> Wasn't remoteproc supposed to be the standard moving forward and UIO would slowly lose support over time?
<Guilherme> I mean, this is the biggest driving force for any change right now, and that was what I've read on a few blogs and docs
<zmatt> well it's a trivial driver to forward-port
<Guilherme> I see
<zmatt> and I personally don't have any intention to switch to remoteproc-pru, it's just objectively worse in almost every way
<Guilherme> It really is, it's been a pain for the last 3 days for some specific stuff, and some instructions are kinda "borked", such as QBBC
<zmatt> I've already helped to forward-port uio-pruss once, I fully intend to do it more as needed
<Guilherme> You cannot use model #1 for example, which makes defines less "powerful" in a sense
<zmatt> ah you're talking about the clpru assembler vs pasm?
<Guilherme> also that, yes
<Guilherme> it's more of a tangent to the whole thing
<zmatt> it also wouldn't be hard to adapt from using the uio-pruss driver to using the uio-pdrv-genirq driver that's been a part of mainline linux since prehistory and will no doubt be around forever more
<zmatt> adding support for that (with DT example) to my py-uio project is still on my to-do list
<Guilherme> I'm probably going to look into that on saturday as well, seems more promising than remoteproc for the moment being
<Guilherme> and for any other moment, for that matter
<zmatt> for 4.19 you can just switch back to uio-pruss and be done
<Guilherme> I'm probably gonna do both, thanks for the heads up regarding the whole situation
<Guilherme> Both as in leave both options open moving forward for other devs
<zmatt> it's funny, I've seen other projects that felt pressure to switch from uio-pruss to remoteproc-pru. and then proceeded to use /dev/mem for shared memory.... at which point you've lost all benefits of remoteproc-pru and are just doing what uio-pruss does but way worse
<Guilherme> Actually, the original project did use shared memory and we moved away from it in this new iteration precisely because of that
<Guilherme> We didn't really need shared memory initially, but it was a "nice-to-have" in that specific case
<zmatt> I mean, remoteproc also uses shared memory, just with an elaborate and inefficient messaging protocol on top of it
<Guilherme> Yea, it's pretty much a massive "zealous gift wrap" kind of situation right now with rpmsg
<zmatt> and remoteproc also always puts the ringbuffers in ddr3 memory, forcing pru to perform reads that have slow and non-deterministic timing
<zmatt> I dug into how rpmsg works since I wanted to add support for it to py-uio ( https://github.com/mvduin/py-uio/ ) but learning how it works made me less motivated to implement it :P
<zmatt> (so it can currently load ELF executables produced by clpru (in addition to raw pasm binaries) but without support for rpmsg or anything in the resource table)
<Guilherme> The more I look into rpmsg, the more I start to think this wasn't a good idea
<zmatt> very little about remoteproc-pru was a good idea
Shadyman has joined #beagle
<zmatt> using C on pru also isn't a good idea, the pru instruction set was designed to be programmed by humans in assembly, not to be targeted by a C compiler, which is probably in part why the code output of clpru is so shit (though it cannot excuse all of the dumb things I've seen clpru do)
vd has joined #beagle
Guilherme has quit [Quit: Client closed]
giort has joined #beagle
otisolsen70 has quit [Quit: Leaving]
the_person48 has quit [Quit: Client closed]
vd has quit [Quit: Client closed]
vd has joined #beagle
waldo323 has quit [Remote host closed the connection]
waldo323 has joined #beagle
vd has quit [Quit: Client closed]
blech has quit [Ping timeout: 260 seconds]
blech has joined #beagle
blech has quit [Ping timeout: 268 seconds]
blech has joined #beagle
blech has quit [Ping timeout: 268 seconds]
blech has joined #beagle
giort has quit [Ping timeout: 252 seconds]
blech has quit [Ping timeout: 265 seconds]
blech has joined #beagle
Guest72 has quit [Quit: Client closed]
<set_> Guest72: Did you see what I typed?
<set_> I have not got the Native_SDK working yet on the BBAI. I think I am close but faltering so far w/ updates and upgrades.
<set_> in particular, the cmake --build . , command is beating me b/c of something. I am working w/ the SGX people slowly to wonder and ponder.