<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]
<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>
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>
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>
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>
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
<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")
<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?
<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.