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). [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. 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? [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? [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. 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. 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. 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! Let the users choise if they want to add and use your additional magic and if they want to spend their resources on that. 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. -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/6c5d6da3-6465-4c67-a092-b54b8cc89871%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
