<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>
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"
<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]