> On Jun 24, 2016, at 6:02 PM, Suman Anna <[email protected]> wrote: > > 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. Problem with that approach is no possibility to handle interrupts, security is problematic and developers have to recreate almost everything from scratch. The calling mechanism (VRING) between PRU and ARM is quite efficient, but as TJF explained, the calling convention using multiple parameters does impact PRU performance. Perhaps look at ways to make the call work with less PRU cycles. I think TJF is confusing throughput with latency. From the BeagleLogic project, they were able to achieve better throughput with RemoteProc, but TJF is able to achieve lower latency with PRUSS_UIO. From what TJF explained, the latency occurs because of 5 parameters that must be pushed onto the stack for each call. > >> >> 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. This is what I like most about RemotProc/RPMSG, in that you are using the same framework between ARM, PRU, DSP, etc. > > 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. Yeah, so long as you don’t need security, interrupt handling, virtual peripherals (firmware defined devices), etc, why not use a hack to accomplish your task. I guess there is a reason why Linux doesn’t have a lot of userspace drivers. > >> >> 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. BBB has two kernels, the “bone" kernel which continues to use PRUSS_UIO and the “ti” kernel which tracks TI’s kernel development and support RemoteProc/RPMSG. From Robert Nelson comments in this thread, he does pull in RemoteProc/RPMSG patches from git.ti.com. > >> >> 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. For those developers who don’t want RemoteProc/RPMSG, they use Robert Nelson's “bone” kernel. > >> 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. Suman, you have done very good work. Please take the criticism as suggestions on how to make RemoteProc/RPMSG better. We understand that you have many other responsibilities at TI and we want to be respectful of your time. Thank you again for all your help.
Regards, John > > 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/8406B86A-FC65-4A73-A979-A7F409E07220%40gmail.com. For more options, visit https://groups.google.com/d/optout.
