<mixotricha>
Hi everyone. I have a BBB that has been sitting about for a long time. Now I would particularly like to use it to do some development work using the PRU and I am wondering what is the best Linux to get for this. It has Ubuntu on it right now. Somewhere around 18. I thought I would be able to just put the tools on to that. But after a bit of head
<mixotricha>
scratching appears to not be the case. I'd prefer to do the development native on the device itself.
<zmatt>
mixotricha: ubuntu is not officially supported (even though unofficial images do exist), the recommended images are Debian
<zmatt>
and the IoT images include the toolchain for pru
<zmatt>
there's basically two ways to write code for pru: the original way was using the pru assembler (pasm), loaded onto pruss using the uio-pruss driver and libprussdrv. later TI made a C compiler (even though the instruction set was designed for assembly programming and really not for being targeted by a C compiler)
<zmatt>
that C compiler peoduces ELF executables which can't be loaded by libprussdrv, the new mechanism is the remoteproc-pru driver where the kernel handles the loading instead of userspace
<zmatt>
alternatively I've made a python library, py-uio, which uses the uio-pruss driver and is able to load both raw binaries as produced by pasm and elf executables produced by clpru (the c compiler)
<zmatt>
(and py-uio also makes it easy to directly inspect and interact with the pru subsystem and its two pru cores)
<mixotricha>
Thanks. I have Debian on it now. I have a bit of assembly written for the PRU that I would like to play with. It apparently does SPI over the PRU. What would be the best way to move that over to the C. I am quite comfortable in the C but a bit more of a learning curve when it comes to the assembly.
<zmatt>
"does SPI" in what sense? if it's bit-banging then it's probably too timing sensitive to do in C
<zmatt>
one of the big benefits of PRU is that its simple and deterministic instruction timing and dedicated gpio hooked into registers makes it easy to implement custom protocols in software
<zmatt>
but writing in C obliterates that
buzzmarshall has quit [Quit: Konversation terminated!]
AKN has quit [Read error: Connection reset by peer]
Shadyman has quit [Remote host closed the connection]
mixotricha has quit [Ping timeout: 256 seconds]
mixotricha has joined #beagle
<mixotricha>
Ah mainly I was just going to port it over to C to fit in to some of the gcc-pru examples I have looked at written in C.
<zmatt>
oh right, gcc-pru exists too
<zmatt>
I didn't know anyone actually used it
<mixotricha>
I just figured since I am comfortable with C. The SPI example I was looking at is here.
<zmatt>
its elf executables don't actually comply with the pru abi so I don't think py-uio can even load them, though I think they did patch the linux driver to understand what pru-gcc produces
<mixotricha>
I have a need to do fast SPI to a bus for a bit of vintage S-100 hardware. Just seeing how far I can go with this. The standard GPIO isn't fast enough and we don't think the SPI is quite fast enough on its own to get us up to the 10MHz bus speed we would like.
<zmatt>
the SPI controllers support up to 48 MHz
<mixotricha>
Will they really do that though given latency in kernel and such like. See the S-100 bus is very time sensitive.
<zmatt>
which timings exactly?
<mixotricha>
( this debate has been going back and fourth in the S-100 group about if the SPI will be fast enough. I say the way to solve that is to bit bang it with the pru ) ..
<zmatt>
do you have details of what exactly you're trying to do?
<mixotricha>
We are putting a beagle bone black on the S-100 bus. Asking for the S-100 bus timing is like asking for the whole IEEE-696 standard. It is a whole bloated manual of timing signals.
<zmatt>
okay so you're not actually trying to do spi
<mixotricha>
Well the SPI is a nice way to handle all of the pins involved and the GPIO on its own is what 3MHz ?
<mixotricha>
The GPIO on its own isn't fast enough. Stage of level shifting and multiplexing out to a 16 bit SPI chip seems a clean way to go off the S-100 bus.
<zmatt>
if you're going to be accessed by a remote bus master then of course the question is also how you're going to service the requests... like, will the remote bus master just access some piece of memory in pruss or what?
<mixotricha>
If the SPI is fast enough on its own this is easy ...
<zmatt>
ehh, that would just make things slower
<mixotricha>
I thought the non PRU GPIO topped out at about 3MHz max?
<zmatt>
like, pru is the fastest thing pru can do, it can read its gpio inputs or modify its gpio outputs in a single clock cycle
<mixotricha>
Oh I forgot to say the other reason for the SPI was because it is a nice way to multiplex down all the pins.
<zmatt>
non-pru gpio doesn't have guaranteed deterministic timing so it's presumably not useful here
<mixotricha>
yeah hence go to the PRU and bit bang some SPI ... because you get what 24 pins?
<mixotricha>
IS it 24 pins? ... but you get two don't you ?
<mixotricha>
S-100 bus is also lots of pins. 100 of em. Organic evolved legacy mess.
<zmatt>
ew
<mixotricha>
And capacitance terminated old school
<mixotricha>
not modern path termination though somebody has done a backplane that is modern terminated
<mixotricha>
Somebody has done a PDP project using a Beagle Bone but the difference is that it isn't synchronous.
<mixotricha>
So the timing is not really an issue.
<zmatt>
I know someone implemented some microprocessor bus using pru that was timing sensitive
<zmatt>
I think he used some parallel latch or whatever to get around not having enough pins
<mixotricha>
But really I came here just more for pointers about tools. Like should I used Debian. Should I use the gcc-pru. Are people still using pasm?
<zmatt>
doing 100 pins serially via spi would be suuuper slow, you kinda want to use as many pins in parallel as feasible
<mixotricha>
What is the best way to go about setting up a tool chain to use the pru.
<zmatt>
I wouldn't use gcc-pru
<mixotricha>
Okay. So the pasm?
<zmatt>
since you're in need of both max performance and critical timing you'll definitely want to write in asm
<zmatt>
you can either use pasm or the assembler from the new toolchain.... both have pros and cons
<zmatt>
pasm has some nice features that pru-cgt's assembler doesn't, like being able to scoped variables (e.g. you can declare a scope that declares certain names variables to have certain types and be bound to certain registers, and then in your main code you can tell the computer when you enter/exit that scope and all variables declared in that scope and then available, and iirc pasm also checks that you ...
<zmatt>
...don't enter two scopes with overlapping register uses)
<mixotricha>
This bit of asm that does the big banging of SPI over the PRU was done using pasm.
<zmatt>
pasm was designed for humans writing assembly, pru-cgt is centered mainly around the C compiler hence its assembler is mainly designed to consume machine-generated asm
<zmatt>
note that the spi code you're looking at is an spi master
<zmatt>
that's not really what you're after, you're not the one creating the timing
<mixotricha>
I had pondered that. The thinking was since that thing is so much faster than the 10MHz the s-100 bus can do
<mixotricha>
it could master the whole thing quite comfortably.
<mixotricha>
But how the hardware is done is next problem .... first problem was just toolpath
<mixotricha>
I think I will go look at the pru-cgt thing thanks
<zmatt>
being a master is generally much easier than being a slave, since if you're the clock master then you can typically just go slower when needed since other devices and using your clock
<zmatt>
why?
<zmatt>
I'd suggest pasm
<zmatt>
the main reason to use ti-cgt's assembler would be if you want to use the remoteproc-pru driver instead of uio-pruss, but remoteproc-pru is overall more limited and especially poorly equipped for high performance data exchange
<zmatt>
and whether it can do 10 MHz depends on how much work there is to do per clock cycle
<zmatt>
if you're going to need to read inputs and/or update outputs in multiple steps using external muxes/latches/shift registers due to insufficient pins then you can still easily run out of time
<mixotricha>
I think I would be more comfortable with the pasm actually as well
<mixotricha>
And I would rather be able to just compile the pru stuff on the device
<zmatt>
you can compile on the bbb regardless of what you use
<zmatt>
my python library ( https://github.com/mvduin/py-uio ) includes both pasm examples and clpru examples (though mostly pasm)
<zmatt>
(since it can load executables from both toolchains)
KartikANK has joined #beagle
balrog has quit [Ping timeout: 250 seconds]
KartikANK has quit [Client Quit]
balrog has joined #beagle
AKN has joined #beagle
Shadyman has joined #beagle
CrazyEddy has quit [Ping timeout: 256 seconds]
mag has quit [Ping timeout: 252 seconds]
mag_ has joined #beagle
ikarso has joined #beagle
mag- has joined #beagle
mag_ has quit [Ping timeout: 256 seconds]
rob_w has joined #beagle
mixotricha has quit [Ping timeout: 256 seconds]
otisolsen70 has joined #beagle
florian has joined #beagle
Guest76 has joined #beagle
<Guest76>
We using Beagle bone Black version C and looking for 3D step file. Can you help us with that?
Shadyman has quit [Remote host closed the connection]
Guest76 has quit [Quit: Client closed]
paulbarker has quit [Quit: Connection closed for inactivity]
starblue has quit [Ping timeout: 240 seconds]
johanhenselmans has quit [Quit: johanhenselmans]
starblue has joined #beagle
lucascastro has quit [Ping timeout: 252 seconds]
johanhenselmans has joined #beagle
lucascastro has joined #beagle
<zmatt>
rcn-ee: whatever is going on with 5.10 wasn't a problem with my kernel build, 5.10.100-ti-r40 is also broken on my bbx15
<zmatt>
like, shortly after boot something goes horribly wrong... and usually it spontanously reboots, though it seems for some reason it doesn't this time
<zmatt>
right now if I try to access any file (even in proc or sys) the process hangs (but killable with ctrl-C)
<zmatt>
no that interrupt-parent doesn't make any sense
<zmatt>
that can't possibly work
<rcn-ee>
without a value we get: src/arm/overlays/AM57XX-PRU-UIO-00A0.dts:25.9-38.3: Warning (interrupts_property): /fragment@2/__overlay__: Missing interrupt-parent
<zmatt>
that's just an incorrect warning caused by dtc ignoring that it's an overlay and not a complete dts
<zmatt>
that warning (and a bunch of other ones) should just be suppressed when compiling overlays, or a bug filed against dtc
xet7 has quit [Ping timeout: 245 seconds]
xet7 has joined #beagle
<zmatt>
it's also just straight up the wrong interrupt-parent, the correct one is inherited from an ancestor node
<zmatt>
(looks like it's inheriting interrupt-parent = <&crossbar_mpu> from the root node)
Guest1 has joined #beagle
<Guest1>
Hi guys! I have some questions related to a PRU unit of BBB. Have anyone worked on that before?
<zmatt>
no, you're the very first person :P
<Guest1>
Haha sadge
<zmatt>
so what are the questions?
<Guest1>
I do some experiment with PRU and the data is saved in a PRU register. Can I get the value outside the linux enviroment some how?
<zmatt>
rcn-ee: so is 5.10-ti actually working for you on am572x ? on my bbx15 it consistently hangs soon after boot (and then gets reset, presumably by the watchdog), with nothing logged by the kernel
<rcn-ee>
wonder, what version of u-boot is on your board?
<rcn-ee>
but yeah, it booted fine yesterday..
<zmatt>
hah, I was *right now* thinking "hmm, maybe I should try updating u-boot"
<zmatt>
no I mean, it boots normally but then within a few seconds to a few minutes all file access (including virtual, like proc) starts to hang
<zmatt>
really bizarre
CrazyEddy has quit [Ping timeout: 240 seconds]
<zmatt>
rcn-ee: hmm, looks like this u-boot version still configures nonsense pinmux (intended for the full EVM instead of the bbx15), preventing that was actually the main reason for custom-building u-boot
<zmatt>
but, let's see if it fixes the 5.10 issue
<rcn-ee>
yeah, we still need to setup a better default..
<zmatt>
btw don't forget to remove the interrupt-parent
<zmatt>
(it definitely won't work with interrupt-parent misconfigured)
<Guest1>
So how can I get the shared memory out of PRU? zmatt
<zmatt>
rcn-ee: it actually looks like updating u-boot fixed the problem... that's... fascinating
<zmatt>
never mind
<zmatt>
I spoke too soon
<zmatt>
Guest1: using py-uio you mean? the way to use shared memory depends a bit on what tools/environment you're using (on both sides)
<zmatt>
py-uio has a few examples that use shared memory
<zmatt>
libprussdrv also supports shared memory.... dunno if remoteproc-pru finally supports shared memory or if people still work around that
<Guest1>
Thank man! I still a little confuse but I try to look at that :)
<zmatt>
also, the only piece of actual documentation I've written for py-uio so far (sorry) is about using shared memory, although it's not exactly a tutorial and more reference documentation: https://github.com/mvduin/py-uio/wiki/Memory-access
<zmatt>
but like I said, it depends on what you're using (or planning to use), and you haven't really mentioned anything on that topic yet
<zmatt>
(I'm obviously most familiar with py-uio... since I wrote it :P )
<zmatt>
stream.py and stream-c.py are more complicated examples that use a ringbuffer in shared memory to send a continuous stream of messages from pru to python (stream uses pru firmware written in asm, stream-c uses pru firmware written in C)
ketas has joined #beagle
<Guest1>
Thank a lot! In this ddr-ping.py example, How can I take the value 0x1234 out to linux enviroment example?
<zmatt>
?
<zmatt>
how much background in programming do you have exactly?
ogra has left #beagle [Ex-Chat]
ogra has joined #beagle
<Guest1>
Not much! and i am also see on assembly for my example so it's confusing for me
<zmatt>
yeah, pru is not the easiest environment to write software for, it may not be the best idea to start out with that if you have very little experience with programming
<zmatt>
what do you want to do with it?
<Guest1>
yeah. I know but I still have to do it! The task is: I have 16 bits value from the shared memory example. The task is I need to read it in Linux environment. Is this making sense?
<zmatt>
not really no
<zmatt>
like, it's vague to the point of being meaningless
<zmatt>
and you also haven't answered what you're trying to do with pru in the first place
<zmatt>
I don't understand, this is some existing code which has already been designed with a particular shared memory protocol, which moreover has already been implemented in a driver https://github.com/openvlc/OpenVLC#design-of-openvlc
<Guest1>
yes, it is! They didn't provide the output of the r3 value in the end. So I need to extract this value outside
<zmatt>
like, whatever it is you're trying to do, it is clear you're seriously out of your depth...
<Guest1>
Okey! Thank for your help
<zmatt>
what do you even mean "the r3 value" ? r3 is just a register used here
<zmatt>
and it's clearly storing the received data into shared memory
<zmatt>
like, I really don't know how to help you since you don't even have enough background to be able to communicate what you're trying to achieve
<zmatt>
this is just not very beginner-friendly stuff
<Guest1>
Yes I see, the data storage in r3 is what I need. maybe I don't explain it well enough
<zmatt>
yes I see it's using r3 to accumulate the received data, and then it writes that into a shared memory buffer
<zmatt>
the diagram at the top also shows that this buffer is in fact shared between the two pru cores, and the second pru receives this data, processes it in some way, and finally writes it to a buffer that's read by the linux driver
<zmatt>
like, your claim that it "doesn't output" this value is bizarre, since transferring this data to linux is the entire purpose of this code
<zmatt>
so you're probably just severely misunderstanding things
<Guest1>
So the value already goes into the Linux environment. So maybe I only need to look for it on the driver's side of it
<Guest1>
Thank you a lot for clearing the misunderstanding! Have a great day
<jfsimon1981>
Good evening, do you know how to change default resolution ? hdmi renders at 1280x800
<jfsimon1981>
it seems this needs to be set suring boot, i think a kernel or uEnv setting
<jfsimon1981>
i'd like to lower a bit the resolution for performance
<jfsimon1981>
thanks
<zmatt>
by default it'll pick what it thinks is a sensible resolution, which can then later be changed by whichever process becomes the master of the display device (e.g. X11, Wayland, or an application that directly renders fullscreen to the display)
<jfsimon1981>
ah
<zmatt>
the initial resolution can also be overridden using a kernel parameter
<jfsimon1981>
i'll check it
Guest1 has quit [Ping timeout: 256 seconds]
<zmatt>
but typically applications that use the modern kernel graphics api (direct rendering manager) will set the resolution themselves anyway, so the kernel parameter is then not very relevant since it would only apply during boot
<jfsimon1981>
it seems i only see available a set of 1280 with different bpp, no other resolution listed
<zmatt>
how are you looking?
<jfsimon1981>
i don't quite understand yet
<jfsimon1981>
through lxde parameters
<jfsimon1981>
i also listed them through sfml videomode inquiry
<zmatt>
what video driver does x11 use?
<jfsimon1981>
how can i check this ?
<zmatt>
good question
<zmatt>
also, using x11 will obviously degrade performance compared to rendering directly to the display
<jfsimon1981>
ah
<jfsimon1981>
it's not quite fast, kind of works
<jfsimon1981>
since this app is 2d only i have'nt installed the sgx driver, although in the future i probably run it through opengl via sgx acceleration somehow
<jfsimon1981>
at the moment it pins a bit the processor.
<zmatt>
this at least shows which video drivers are installed: dpkg --list 'xserver-xorg-video-*' | grep ^ii
<zmatt>
is there really no better way to check which one is used than grepping the x11 server's log? :/
<zmatt>
also looks like basic drivers aren't packaged separately anyway
<jfsimon1981>
are you using hdmi too ?
<jfsimon1981>
i don't think 2d is nor can be accelerated, bad luck
<zmatt>
never heard of this sfml before... it sounds a bit like sdl ?
<zmatt>
no, but obviously how you render graphics can have significant impact
<jfsimon1981>
well it's using the back end, x11 don't know exactly, but it's an interface, very good library
<jfsimon1981>
it can work with opengl too although i'll develop that part a bit later
<zmatt>
that will probably be slower, unless you want to do actual 3d rendering
<zmatt>
looks like sdl nowadays supports rendering directly using drm/kms rather than x11
<jfsimon1981>
i did some tests about 3/4 years ago and it's much much faster to render in 3D through sgx integrated graphic card, than even simple 2D animations running through the cpu
Guest115 has joined #beagle
<jfsimon1981>
ok
<zmatt>
well, it'll depend on how you're doing the rendering obviously
<zmatt>
but maybe you're right, maybe I'm a bit too pessimistic about the gpu
<zmatt>
I know qt5 was slower with gpu than without it, but maybe it was just doing stupid things
<zmatt>
or maybe we were, dunno, it was a while ago
Guest115 has quit [Client Quit]
<zmatt>
hmm, libsfml depends on libgl1 (opengl)
<jfsimon1981>
ah
<jfsimon1981>
i used to run a small 3D animation with stuff for x-plane, it rendered very good, and i think Qt might need 2D acceleration though i'm not an expert at all with this
<zmatt>
no I was using qt with eglfs backend, which uses OpenGL ES 2.0
<jfsimon1981>
indeed sfml runs opengl and a few other libraries, it should be lightweight.
<zmatt>
opengl is not lightweight
<jfsimon1981>
ok strange
<jfsimon1981>
then it worked on the gpu
<zmatt>
(and opengl (not-ES) also can't be gpu-accelerated on the bbb)
<jfsimon1981>
yes i mean opengles
<zmatt>
sfml depends on gl though, not gles
<jfsimon1981>
i worked a bit with it and pvr tools, they're quite interesting
<jfsimon1981>
rights, i don't think i used sfml with opengles ever, not checked it
<jfsimon1981>
Can i ask, do you see multiple resolutions available on the screen setup ?
<zmatt>
I'm not using graphics on any beaglebone here, and even when I did do something with graphics I didn't use x11
<zmatt>
it's possible your x11 is using the fbdev driver, which uses the legacy fbdev interface and doesn't have the ability to change resolution
<jfsimon1981>
indeed i see all video modes there
<jfsimon1981>
from 720x400 to 1280x800
<jfsimon1981>
and i see "fb" with only one, 1280x800 16 bits
<zmatt>
that's the framebuffer allocated for the legacy fbdev
<jfsimon1981>
ok
<zmatt>
(also used for things like the console / VTs)
<jfsimon1981>
a bit too complex yet to grasp, i'll experiment with it
<zmatt>
yeah this is just a raw information dump
<zmatt>
if x11 is indeed using the fbdev driver then using the modesetting driver instead should allow runtime changes to the resolution
<zmatt>
or, like I said, you can force a different initial resolution using a kernel parameter, configured in /boot/uEnv.txt
<jfsimon1981>
i mean about the driver stuff, it seems i should change driver to get the right res
<jfsimon1981>
that's the simpler solution
<zmatt>
or, y'know, ditch x11 :)
<zmatt>
(if appropriate)
<jfsimon1981>
don't know, i'll check the uEnv, i'm doing it now
<jfsimon1981>
thnks Matt, work a charm
<jfsimon1981>
added in uEnv.txt => optargs=video=HDMI-A-1:640x480
<zmatt>
optargs? wtf is that, I've never seen that
<jfsimon1981>
no idea, that's how they recommend to do it, it passes a kernel instruction
<zmatt>
normally there's a cmdline= variable to which you can append custom kernel parameters (such as video=HDMI-A-1:640x480), and an example for that in the comments
<zmatt>
hm, it looks like u-boot indeed also accepts kernel parameters in an optargs variable, in addition to the cmdline parameter that's normally used
<jfsimon1981>
ok, it works though
<zmatt>
I've never seen or heard of it before though
<zmatt>
it's probably some backwards-compatibility thing
<jfsimon1981>
ok
<zmatt>
also I think you omit the name of the video output, e.g. video=640x480
<jfsimon1981>
can't tell
<zmatt>
well normally /boot/uEnv.txt explains which variables are available for use in its comments