Actually, it's just my locally cross built kernel that have the large
modules, for the official *.deb, the *.ko objects are separate in the
linux-image-`uname -r`-dbg package. 
(for gcc-4.7 + that is..)
Yeah, just adding a blacklist for users who want to tune things is the
easiest way.
Regards,
Actually, it’s just my locally cross built kernel that have the large modules, for the official *.deb, the *.ko objects are separate in the linux-image-
uname -r-dbg package.(for gcc-4.7 + that is…)
Yeah, just adding a blacklist for users who want to tune things is the easiest way.
Regards,
That’s pretty much what my script on https://github.com/wphermans/bbb-cleanup does. When I first wrote this script, for some reason the blacklist method was not working, but the fake install was. Would be very trivial to change the script to do a “proper” blacklist.
Question though Robert.
debian@beaglebone:~$ sudo depmod -ae /* Ignore warning */
debian@beaglebone:~$ sudo update-initramfs -u /* Changes will take effect next boot */
What do these two tools actually do in the context of modules and initrd images ? I always assumed this had some
effect on what is actually loaded from an initrd, but I've never honestly looked into it. . .
Ok thanks Robert,
Yes, well, some rationale at least from my side as input. After I’ve checked my options to go for PRU, I found there’s both remoteproc and uio. At first glance, I did not like the remoteproc implementation as it appears to be more of an interrupt based approach. I think this is more towards userspace program on the main processor that does not do that much harm, but for the PRU being the opportunity to do hard real time stuff (although not really interrupt based but polling-wise) a somewhat weird concept choice. I’ve seen an idea to let PRU1 handle the interrupts, and use PRU2 to interact with PRU1 for the real realtime stuff which does sound like a compromise. So my “instinct” for what it’s worth was to steer clear of remoteproc and use uio. It fitted my application better as well to have shared memory both accessible to PRU and userspace. As far as I could tell a couple of weeks ago this is not possible with remoteproc. I might be wrong though, but this is how I came to the conclusion to go for uio.
Regards,
Maarten
Hello William,
Nice page there William.
Yes we have the right installation written above for using uio. Documenting it on eLinux seems to be the next logical thing also. I’m opting to help here, already registered with my account on eLinux, or go for a personal page as well. There’s a weak spot though. I see the pace at which kernel and surroundings changes is quite fast if you take a minute to look back, I think therefore the info, once written down, is outdated quite fast as well consequently. Take a look at this page for instance: http://elinux.org/Ti_AM33XX_PRUSSv2. It still assumes uio, but remoteproc now being the preferred/standard. So I think there needs to be a tighter link between developer and documentation to keep all in sync. The beagle bone project would benefit from this tighter link to my opinion. Thinking out loud, also here, a more modular approach on the beagle bone software would help. Like to use uio? Use this kernel, install this .deb, and your ready to go (ideally). Any changes under the hood are then kept inside the .deb that is affected, and documentation (or installed base so to speak further down the line) is much easier to maintain / keep up to date from user perspective.
My 2 cents… but again, happy with the help offered!
Regards,
Joseph
Well, I like to document stuff, as I’m a very technical person. The problem is, when you have a professional gig, and other things all happening at the same time. Some things just don’t get done as often as I’d like. There is also a big difference between helping someone here, and writing blog post on that same subject. It takes a considerable amount of time to blog on things. As people, at least I want things to be accurate, and concise as possible. Where helping out here: I can be more casual as the nit picks of this and that do not matter so much as just achieving the end goal.