Shadyman has joined #beagle
vagrantc has joined #beagle
vagrantc has quit [Quit: leaving]
rob_w has joined #beagle
rob_w has quit [Client Quit]
rob_w has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
xet7 has quit [Remote host closed the connection]
xet7 has joined #beagle
Shadyman has quit [Remote host closed the connection]
_whitelogger has joined #beagle
_whitelogger has joined #beagle
xet7 has quit [Remote host closed the connection]
M-blaise has quit [Ping timeout: 272 seconds]
xet7 has joined #beagle
Dalgas has joined #beagle
_whitelogger has joined #beagle
Dalgas has quit [Ping timeout: 268 seconds]
Dalgas has joined #beagle
Dalgas has quit [Ping timeout: 244 seconds]
rob_w has quit [Quit: Leaving]
<dinuxbg> jkridner: Can you please suggest a suitable landing page for the PRU processor?
<dinuxbg> The TI wiki was removed from the GCC reference docs: https://gcc.gnu.org/pipermail/gcc-patches/2021-May/571488.html
<dinuxbg> I can't find a similar official page to describe the PRU architecture. bbb.io/pru is stale and full of examples, and does not include CPU description.
<jkridner> I think we can get TI to give us the content of some pages.....
<jkridner> what should we put on bbb.io/pru ?
<jkridner> dinuxbg: let's make beagleboard.org/pru the landing page and please give feedback on what needs to be added to make the page successful.
* GenTooMan has no idea why TI suddenly want to get rid of there wiki but suspects IT people were heavily involved in it, not the people who needed or used it.
<GenTooMan> want == wanted but that was 5 years ago they locked the wiki now they are removing stuff? hmm
<zmatt> jkridner: btw did you see my email? as far as I'm concerned we're ready to update bbb.io/chat to point to here (logs are up, webchat is up, matrix brige is up)
<jkridner> dinuxbg: I did some updates for some more TI links on bbb.io/pru, but please let me know what you feel is lacking. I cannot find a good document for the architecture at first glance. :-(
<jkridner> zmatt: ok, switching it.
<jkridner> where are the new longs?
<jkridner> logs.
<zmatt> I put all the links in the email
<jkridner> sorry to be so lazy.
<jkridner> k
<jkridner> kiwi is timing out. :-(
testkiwi has joined #beagle
<testkiwi> just making sure this is currently working.
<zmatt> jkridner: you missed one "Freenode" (in the line of text below the big link)
<zmatt> jkridner: and maybe update the links to use libera's webchat? ( https://web.libera.chat/#beagle )
Guest7229 has joined #beagle
<zmatt> it seems to work fine for me
Guest7229 has quit [Client Quit]
Guest89 has joined #beagle
<Guest89> yeah, seems fine.
* jkridner cannot remember how to open the bridged matrix room.
<jkridner> ugh. something is wrong with my matrix.org key on chat.beagleboard.org.
<jkridner> Failed to find any key to satisfy VerifyJsonRequest(server=beagleboard.org, key_ids=['ed25519:a_CEGr'], min_valid=1622566270919)
Guest89 has quit [Client Quit]
<zmatt> jkridner: I don't think any setup is required to use their portal bridge? https://twitter.com/matrixdotorg/status/1398366903404482564
<zmatt> but I guess you mean plumbing
jkridner[m] has joined #beagle
<jkridner[m]> testing matrix bridge.
testkiwi has quit [Quit: Connection closed]
rcn-ee has joined #beagle
Shadyman has joined #beagle
xet7 has quit [*.net *.split]
signal11 has quit [*.net *.split]
jkridner has quit [*.net *.split]
tbr has quit [*.net *.split]
tbr has joined #beagle
jkridner has joined #beagle
signal11 has joined #beagle
xet7 has joined #beagle
<dinuxbg> jkridner: The youtube video on bbb.io/pru cannot be opened. It also mentiones a workshop and SW images from 2014, which is way outdated.
<zmatt> speaking of pru, I should really add more documentation to py-uio... some day
<dinuxbg> Those stale links perhaps should be removed.
<dinuxbg> The first paragraph should be a brief "about PRU" like the short description in https://training.ti.com/pru-training-series
<dinuxbg> And most importantly for gcc docs, it should include links to assembler guide (spruij2.pdf) and opcode information: https://github.com/dinuxbg/gnupru/wiki/processors.wiki.ti.com-Programmable_Realtime_Unit
xet7 has quit [Remote host closed the connection]
<zmatt> how's pru gcc these days? I guess maybe I should add support for its custom ABI to py-uio some day
<dinuxbg> zmatt: It's alive and well. Regression-tested daily: https://gcc.gnu.org/pipermail/gcc-testresults/2021-June/697120.html
<mru> what about progression?
<zmatt> dinuxbg: also what exactly do you mean by ldi32 relaxation? the linker can reduce it to a single mov and fix up all relative branches that cross it?
<dinuxbg> mru: Recently --gc-sections option was enabled. What progress would you like to see?
<dinuxbg> zmatt: Imagine you have "ldi32 r10, LABEL1". If LABEL1 turns out to fit into 16 bits, linker will put only one "ldi r10, LABEL1" opcode.
<dinuxbg> zmatt: If not, then linker will put two "ldi32 r10.w0, ...; ldi32 r10.w2 ..." opcodes. That's transparrent to user.
<zmatt> right, that's what I meant (should have said ldi instead of mov)... so the compiler annotates _all_ branches with relocation info?
xet7 has joined #beagle
<zmatt> yeah, I see... PRU_U8_PCREL, PRU_S10_PCREL
<dinuxbg> Yes. That's why I had to invent some GNU relocations in order to implement relaxation.
<dinuxbg> jkridner: Thank you. It looks much better now. I'll submit a patch to update gcc docs.
<zmatt> it's a shame pru gcc didn't manage to stick to TI's ABI, especially w.r.t. loading and function pointers
<jkridner> yeah, binary compatibility might have been nice.
<zmatt> I think if you'd currently try to load a pru gcc executable with py-uio you'd just get "Invalid segment load address"
<jkridner> OK, I've stopped hacking for now.
<jkridner> please provide additional feedback via https://github.com/beagleboard/Latest-Images/issues
<dinuxbg> I did try, but different code and data pointer sizes would have required rather deep GCC intervention.
<dinuxbg> Also binutils does not support different address spaces.
<zmatt> how do other microcontroller targets handle this? surely gcc for 8-bit avr doesn't use 32-bit function pointers
<zmatt> oh right, all of its pointers are 16-bit, so that's not quite the same as having 16-bit function pointers and 32-bit data pointers
xet7 has quit [Remote host closed the connection]
<dinuxbg> Yes, avr linker uses 32bit addresses internally.
<zmatt> but not in the ABI
<zmatt> what the linker uses internally is the linker's own business :P
<dinuxbg> Issue should be easily fixed by stripping the upper IRAM address bits.
<zmatt> yes I understand how to fix it, I just... haven't yet
<zmatt> fortunately nobody seems to use pru gcc
<zmatt> so the issue hasn't come up yet
<zmatt> (or possibly nobody uses py-uio with ELF executables)
<zmatt> actually no I think some people do
<zmatt> looks like your loader will break if there are multiple data sections
<dinuxbg> I'm playing primarily with remoteproc :)
<zmatt> does remoteproc support shared memory already, or are people still working around that using /dev/mem or uio?
<dinuxbg> You can easily support it in kernel space. I think what we're missing is a UIO-emulation driver in kernel, which uses remoteproc. Could be a good GSOC task for next year.
<zmatt> not sure I'd say we're "missing" that, you can just use the uio driver
xet7 has joined #beagle
<zmatt> and I'm talking about shared memory with userspace of course
<zmatt> I understand remoteproc has its uses for people who want to write kernel code that interacts with pru code, but most people don't, and for userspace code remoteproc is just a restriction on functionality compared to uio
Guest3148 has joined #beagle
pbrobinson has joined #beagle
zjason has quit [Read error: Connection reset by peer]
zjason has joined #beagle
outrageous has quit [*.net *.split]
outrageous has joined #beagle
bldr has joined #beagle
djinni has joined #beagle
Guest3148 has quit [Quit: Client closed]