Hi TJF,
On 06/18/2016 10:23 AM, TJF wrote:
> Hi Suman, thanks for your statements.
>
> [Suman: Where do you use this from, I assume userspace? Using what - Shared
>> DRAM or regular PRU DRAM.]
>>
>
> Yes, libpruio is a userspace library. I'm not familiar with your
> terminologie: Shared DRAM = SRam (12k@0x10000) and PRU DRAM = DRam
> (2x8k@[0x0|0x2000]), right? I use the later (similar to your solution).
Yeah, same ones. I don't use SRAM for PRU Shared Data RAM, as I use it
to mean the regular on-chip memory.
>
> [Suman: You don’t need to unload and reload the driver, the individual PRUs
>> can be rebooted using sysfs bind and unbind without affecting the other
>> PRU.]
>>
>
> Reloading the kernel module for firmware updates is I what read several
> times at this forum. I didn't test yet. Sorry, if I confuse things here.
Yeah, it has come to my notice that this was being suggested previously
on TI forum threads not only for PRUs but for DSPs or IPUs on other SoCs
as well. The bind/unbind does give specific control for a core.
>
> John asked alreay: Where can we find a tutorial / example on updating
> firmware the correct way? A further question: often I reload just a part of
> the IRam. I guess your concept doesn't support that?
Why, it is supported. There are no distinctions made between IRAM,
DRAM0/1 or Shared DRAM. The ELF loader just goes by the program headers,
so if the new image only has a program header that loads into IRAM, then
it just loads that.
>
> [Suman: As for remoteproc driver, it really doesn’t matter what
>> assembler/compiler is used for building a firmware image. Remoteproc core
>> is standardized on ELF, and there is no reason to invent another format. As
>> it is, the plain binary format is a problem for PRUSS since its address
>> space is not unified (Address 0 for both IRAM and local DRAM). I don’t
>> recall how prussdrv is managing this, or if they only deal with IRAM from
>> the binary and leave the data sections for the application to copy over the
>> interfaces to use Data RAMs. At the moment, all you would need is a small
>> script to convert your binary into an ELF using objcopy to use with PRU
>> remoteproc driver.]
>>
>
> Seconding John: Where can we find a tutorial / example on how to load a
> fimware image cerated by the pasm assembler?
I don't know if pasm assembler is still a supported tool by TI. If so, I
will work with Jason Reeder to try to get something documented on the TI
wikis or in PRU Software Support documentation.
Anyway, here's some basic steps (thanks to a colleague) in converting a
bin file to an ELF image,
1. /* Convert your binary to prelim ELF */
objcopy -I binary -O elf32-little --rename-section .data=.text
<input.bin> <output.tmp>
2. /* Mark .text as executable, PRU remoteproc makes the distinction
between IRAM and DRAM0 based on the executable flags */
objcopy -I elf32-little --set-section-flags .text=code,alloc,load
<output.tmp>
3. Add a program header for loading the text
ld -n --accept-unknown-input-arch <output.tmp> -T linker_pru0.txt -o
prueth-pru0-firmware.elf --oformat=elf32-little -o <final-output.elf>
An example linker_pru0.txt is as follows,
SECTIONS
{
.text 0x0 : { *(.text); }
.resource_table 0x0 : { *(.resource_table); }
}
If you have a resource table binary data, that can be added in step 1 as
well, eg.
objcopy -I binary -O elf32-little --rename-section .data=.text
--add-section .resource_table=<rtable.bin> <input.bin> <output.tmp>
Obviously, a lot depends on what other data/sections you have within
your firmware in terms of your linker file and resource table section
placement.
Once I add the evt->channel->host interrupt mapping to DT for MPU, the
need for a resource table for MPU-related interrupt handling will mostly
go away. Until then, the interrupt mapping needs to come through
resource table, or if thats too painful, let the firmware code deal with
the mapping.
As for reloading a new non-ethernet firmware,
echo <pru-device> > /sys/bus/platform/drivers/pru-rproc/unbind
change correspoding firmware in /lib/firmware/
echo <pru-device> > /sys/bus/platform/drivers/pru-rproc/bind
>
> [Suman: Right, the basic infrastructure is already there and you would need
>> only to build upon it. For eg., at the moment, all you would need is a
>> small kernel module, use pruss_request_mem_region to gain ownership of PRU
>> memories, export it to userspace and use it however you want. The
>> interrupts would have to go through kernel though. Maybe it is the same
>> module that exports the above desired sysfs interfaces too.]
>>
>
> Am I reading right here? My message is:
>
> - Reduce resource consumption on a small SoC.
>
> And your advice is:
>
> - Add a further module to a bloated framework.
It is about coming up with a framework that would satisfy both the
kernel and userspace needs as well. With libprussdrv, one simply cannot
use PRU from kernel-mode. Yes, there are gaps at the moment with the
current infrastructure, and I never said it is complete.
Going by your philosophy, you don't need Linux drivers at all. Mmap
everything and do everything in userspace, why bother with the kernel at
all? /dev/mem is your friend.
>
> Are you joking?
>
> Full sure, it's not only me who'd ask: Why should I spend time to extend a
> resource consuming framework that changes every now and then -- why should
> I start to follow a moving target, just to end up with a feature that I
> already have, working reliable since years? And why should hundred other
> developers do the same?
>
> It has been said already. From the BBB point of view your project has
> nothing to offer. There are no MPU, DSP, ... processors. It's just about
> ARM and PRU.
The TI kernel is not just about BBB, there are 4 other SoC families and
multiple boards where PRU is now supported. And we do have userspace
needs as well for Industrial usecases, they will get addressed in the
upcoming months. You might very well find a thing or two w.r.t UIO in an
upcoming Processor SDK release.
Your IPC is too slow. The complete topic is just about
> replacing a "hack" by a "real Linux driver". And this isn't worth to spend
> four times more memory and additional boot time and additional development
> man power, just to get what we have already.
>
> When you aim to develop software for the main stream, replacing a proven
> solution, than YOU have to care about existing standards and start from
> that point.'This means redo your concept.
And may I know how would you have done it if you were to redo it from
scratch supporting both kernel and userspace? You are only looking at it
from userspace angle, and as long as you stick to that, any kernel
framework will indeed look like bloat.
>
> Otherwise, when you want to retain with your extisting infrastructure, it's
> OK as well. But:
>
> - Make it optional. Place it in a separate package. Leave the main
> stream!
Define mainstream. What's mainstream for you is downstream for me. And I
am not aware until recently that the TI kernel is getting merged into
BBB kernel. I don't even know the merge cycle that BBB kernel is
following. The kernel changes I add are geared towards internal TI
releases, and there's always a potential downside for merging the kernel
at random points.
>
> Let the users choise if they want to add and use your additional magic and
> if they want to spend their resources on that.
It is optional, it is not even enabled by default in
omap2plus_defconfig. If one doesn't want to spend time, one can always
go back to how they were using it with whatever patches they had before.
> And do not block TIs kernel
> development nor the BBB PRUSS development with your experimental project.
>
> Please note: the PRUSS are an important topic. They're a major advantage
> the BBB has over its direct competitors, like RPi. When your project
> complicates and slows down the PRUSS development, this endangers the
> complete Beaglebone project.
I understand that it's frustrating that the new framework does not
address all your needs at the moment, and this is an active development
so I will be continuing to close the gaps during the year.
Please work with Jason Kridner for any further issues or concerns, and
he can work internally within TI to raise requirements or prioritize
features for bridging the gaps. You can always post queries on the TI
E2E forum for continued support.
regards
Suman
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/576DD831.3000705%40ti.com.
For more options, visit https://groups.google.com/d/optout.
