heh, it's not about TI's support. It's about TI playing ball with the
community. Instead of rocking the boat. Personally, I could say when I add
the next feature to whatever - To go talk to my mom, because I don't want
to hear it. But that wouldn't be very social would it ?
Yes, we can go back to and older config, but you people could also stop
stepping all over the communities kernels, and then calling it your own.
Right now, I have a stock image with 115M used memory right after a fresh
reboot. I have sound, and driver for both sides of PRU modules ( remoteproc
AND uio ), and I didn't even touch this image. Here, let me just show you
this crap:
debian@beaglebone:~$ lsmod
Module Size Used by
binfmt_misc 8862 1
usb_f_ecm 9336 1
g_ether 4976 0
usb_f_rndis 22191 2 g_ether
u_ether 11898 3 usb_f_ecm,usb_f_rndis,g_ether
libcomposite 43717 3 usb_f_ecm,usb_f_rndis,g_ether
nfsd 261377 2
spidev 7523 0
omap_sham 21340 0
omap_aes_driver 19045 0
pwm_tiehrpwm 4706 0
tieqep 8758 0
pwm_tiecap 3652 0
omap_rng 4423 0
rng_core 7703 1 omap_rng
c_can_platform 6602 0
c_can 9577 1 c_can_platform
can_dev 11820 1 c_can
snd_soc_davinci_mcasp 17079 0
snd_soc_edma 1290 1 snd_soc_davinci_mcasp
snd_soc_omap 3058 1 snd_soc_davinci_mcasp
snd_soc_core 155549 3
snd_soc_davinci_mcasp,snd_soc_edma,snd_soc_omap
snd_pcm_dmaengine 5209 2 snd_soc_core,snd_soc_omap
snd_pcm 83341 4
snd_soc_davinci_mcasp,snd_soc_core,snd_soc_omap,snd_pcm_dmaengine
snd_timer 19788 1 snd_pcm
snd 59495 3 snd_soc_core,snd_timer,snd_pcm
soundcore 7637 1 snd
spi_omap2_mcspi 11148 0
evdev 10695 1
uio_pdrv_genirq 3539 0
uio 8822 1 uio_pdrv_genirq
pru_rproc 12632 0
pruss_intc 7223 1 pru_rproc
pruss 9408 0
Why do I need all this garbage ? I didn't enable it, and I really do not
want, or need it.
debian@beaglebone:~$ free
total used free shared buffers cached
Mem: 504000 115864 388136 4344 16948 34548
-/+ buffers/cache: 64368 439632
Swap: 0 0 0
This is just sickening.
Anyway, it gets old having to go over these images that used to be nice,
clean, and tidy. I guess I'm just going ot have ot start building my own
images again, improve them myself. And not share the changes ? Isn't that
how this community is supposed to work ?
On Fri, Jun 24, 2016 at 6:02 PM, Suman Anna <s-a...@ti.com> 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.
>
> >
> > 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 beagleboard+unsubscr...@googlegroups.com.
> 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.
>
--
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/CALHSORo3Owydt2X%3D59OOa84PotpO8rUDAPKAnB1nMOrWyiMWOQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
