Kernel change and naming convention (for the sake of uio / prussdrv)

[Joseph Heller]

Ok guys, here is my first question on how to change to another kernel version. I'm using a BBG for my omni-robot project, and started opting for using the PRU's to generate accurate variable frequency PWM signals for my stepper motors (my c code was still showing the occasional delays in frequency pulses due to the non-realtime nature of the kernel). At the time, I was using linux-image-4.1.15-bone-rt-r18. I'm not yet convinced to use the remoteproc driver to handle the PRU's, and would like to use the uio driver instead. It boils down to two questions in the end:

1) is it possible to install another kernel image, and how is this done exactly? Unfortunately I managed to get my image on the sd-card unbootable when installing another kernel (bone-kernel instead of ti-kernel). I guess that uEnv.txt is not correctly updated when switching kernels. Actually I forgot to install the kernel headers in the same pass, and this lead to a series of upgrade errors maybe causing the booting issue. I might be able to restore my image somehow if possible, although I still can use the data by just inserting the SD card in my PC.

That let me wonder secondly, I now downloaded a more recent sd-card image (bone-debian-8.4-lxqt-4gb-armhf-2016-05-13-4gb.img with 4.4.9-ti-r25 kernel), but what does this image exactly contain? In the end I'm looking for a kernel version supporting PRU uio drivers enabling me to use the prussdrv.h in my c files. I understood that the bone-kernel is to be used instead of the ti-kernel, although when now having a quick peek into what drivers are actually loaded I see to my surprise uio_pdrv_genirq, so I guess the naming convention of "ti" kernels was changed somewhere in the past, although not entirely sure if this was correct in the first place. 

I made a dump of available kernels of this release, and shows a huge amount of kernels, which more or less show some understandable (but also less understandable) variations. There's for instance
linux-image-4.4.9-ti-rt-r25
but also
linux-image-4.4.9-bone-rt-r10
as well as
linux-image-4.4.9-armv7-rt-x7
and more flavours combinations.

Here's my guess when reading some forum posts:
ti: (with remoteproc instead of uio PRU driver?)
bone: (with uio instead of remoteproc PRU driver?)
dbg: (meaning debug?)
rt: (meaning soft realtime?)

2) The "ti" version seems to be dropped starting the 4.5.0 series kernel, so I guess remoteproc was dropped in the end with newer kernels altogether?

So I think I'm fine with the new downloaded image but feels a bit fuzzy hit& miss if this is the correct one. Anyone some hints or tips where to find some more details on the kernel versioning?

[William Hermans]

1) is it possible to install another kernel image, and how is this done exactly? Unfortunately I managed to get my image on the sd-card unbootable when installing another kernel (bone-kernel instead of ti-kernel). I guess that uEnv.txt is not correctly updated when switching kernels. Actually I forgot to install the kernel headers in the same pass, and this lead to a series of upgrade errors maybe causing the booting issue. I might be able to restore my image somehow if possible, although I still can use the data by just inserting the SD card in my PC.

The traditional Debian way, you use APT. Something like . . .

william@beaglebone:~/dev$ apt-cache search linux-image | grep 4.1.15-bone
linux-image-4.1.15-bone-rt-r17 - Linux kernel, version 4.1.15-bone-rt-r17
linux-image-4.1.15-bone-rt-r18 - Linux kernel, version 4.1.15-bone-rt-r18
linux-image-4.1.15-bone17 - Linux kernel, version 4.1.15-bone17
linux-image-4.1.15-bone18 - Linux kernel, version 4.1.15-bone18

william@beaglebone:~/dev$ sudo apt-get install linux-image-4.1.15-bone-rt-r18
Also keep in mind that you do not need to pipe the output to grep when searching for a suitable linux-image. But if you do not you'll be in store for a hell of a lot more 'noise'. ALso in the context of using grep, there are many other kernels out there so perhaps you want to apt-cache search linux-image |grep 4 (or something ) to get a broader idea of what all is out there.

I guess that uEnv.txt is not correctly updated when switching kernels.

That's a false assumption. Using APT to upgrade kernels has always worked great for me. Trust me also when I say I have literally tested every other kernel version( at least ) in the last 3.5 years. For debian. So I do have plenty of experience . . .

--
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...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e1904f5a-63b2-45fd-985e-2cb96c86fcb3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[William Hermans]

2) The "ti" version seems to be dropped starting the 4.5.0 series kernel, so I guess remoteproc was dropped in the end with newer kernels altogether?

No. That kernel is probably straight out of mainline. Which means it hasn't had either the *bone* or *TI* patchset applied to it yet.

[William Hermans]

By the way, TI's most recent kernels are purportedly supposed to use either remoteproc, or uio_pruss. I say purportedly because I have not personally experimented with that yet, but Robert made a post not long ago about this. So it sounds like right off the bat, all you need to do is load the PRU overlay file to get uio_pruss working. Or a slightly more involved process to get remoteproc working.

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:11:56 PM UTC+2, William Hermans wrote:

The traditional Debian way, you use APT. Something like . . .

william@beaglebone:~/dev$ apt-cache search linux-image | grep 4.1.15-bone
linux-image-4.1.15-bone-rt-r17 - Linux kernel, version 4.1.15-bone-rt-r17
linux-image-4.1.15-bone-rt-r18 - Linux kernel, version 4.1.15-bone-rt-r18
linux-image-4.1.15-bone17 - Linux kernel, version 4.1.15-bone17
linux-image-4.1.15-bone18 - Linux kernel, version 4.1.15-bone18

william@beaglebone:~/dev$ sudo apt-get install linux-image-4.1.15-bone-rt-r18

Well, I used apt-get install. I traced back the command entered when examining .bash_history:
# sudo apt-get install linux-image-4.1.15-bone-rt-r18

[Joseph Heller]

On Wednesday, July 13, 2016 at 10:19:11 PM UTC+2, William Hermans wrote:

By the way, TI's most recent kernels are purportedly supposed to use either remoteproc, or uio_pruss. I say purportedly because I have not personally experimented with that yet, but Robert made a post not long ago about this. So it sounds like right off the bat, all you need to do is load the PRU overlay file to get uio_pruss working. Or a slightly more involved process to get remoteproc working.

Thanks for pointing that out! I think you are referring to this post I think: http://beagleboard.org/Community/Forums?place=msg%2Fbeagleboard%2Fl59Dx8ygxNg%2FGvIzOJSzDAAJ ? Need to check in detail what Robert mentioned in the post. I would have no problem reporting back if this leads to success, which might be something to materialize somewhere in the wiki and would be glad to help. I guess I was looking in the wrong spot trying to find info on the kernel (e.g. here and the wiki and getting started guide referred in it), did not realize I had to search in the Forum.

[John Syne]

Overlay for Remoteproc doesn’t work so you must follow Roberts instructions to select between rproc or uio:

You can swap between rproc and uio for the pruss...

while, uio can be loaded as an overlay, rproc was failing, so we need
to use the dtb-rebuilder...

Step 1:

upgrade to r34 and reboot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.4.x-ti

Step 2:

Install dtb-rebuilder:

git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
dtb-4.4-ti --depth=1
cd ./dtb-4.4-ti/

Step 3: (rproc)

Edit your device tree:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen.dts#L16-L22

nano src/arm/am335x-bonegreen.dts

Change:
/* #include "am33xx-pruss-rproc.dtsi" */ -> #include "am33xx-pruss-rproc.dtsi"
make ; sudo make install

set blacklist:

cat /etc/modprobe.d/pruss-blacklist.conf

blacklist uio_pruss

and reboot..

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CALHSORpdb6XCDeP6-di7cpbFYNtqS3eN_oBSzsGRqCrK4dR8KA%40mail.gmail.com.

[William Hermans]

Well, I used apt-get install. I traced back the command entered when examining .bash_history:
# sudo apt-get install linux-image-4.1.15-bone-rt-r18

So you say it just failed, and when you examined the second stage uEnv.txt file the uname_r variable had not changed to reflect the upgrade ? What kind of power supply are you using, and how  much do you have running on the board ?

Anyway, using APT is the correct way to install a kernel on Debian. Period. Not just for this hardware, but in general. So I would say that you just experienced a glitch that is not usually that happens when upgrading. But when I tell you that I've not experienced this myself in 3.5 years of using this board . . . that's not entirely accurate. I've experienced a few glitches here, and there. I just never dug into what happened. Instead I just tried again, and it worked . . . So maybe nothing is 100% perfect, but it does work if you keep at it.

Heres a tip though. Whenever flashing a new image, or doing anythign like upgrading the kernel. Disconnect, and / or turn off everything non essential. Peripheral wise. ethernet, and eMMC should be fine, but passed that turn every thing else off.

[Joseph Heller]

Thanks William,

I dod not expext a failre either doing apt upgrade / installs of kernels either. Not sure about the uEnv.txt. My /boot directory shows:

bash-4.3$ ls -la
total 33192
drwxr-xr-x.  4 root root    4096 Jul 11 18:04 .
drwxr-xr-x. 21 root root    4096 Jan 24 23:38 ..
-rw-r--r--.  1 root root  134233 Jan 12  2016 config-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root  154972 Jan 21 21:22 config-4.1.15-ti-rt-r43
drwxr-xr-x.  4 root root    4096 Jul 11 18:03 dtbs
-rw-r--r--.  1 root root 4245828 Jul 11 18:04 initrd.img-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 4177318 Jun 20 12:12 initrd.img-4.1.15-ti-rt-r43
-rw-r--r--.  1 root root 4096241 Jun 15 19:26 initrd.img-4.1.15-ti-rt-r43.old-dkms
-rw-r--r--.  1 root root     492 Jan 25 00:41 SOC.sh
-rw-r--r--.  1 root root 3034732 Jan 12  2016 System.map-4.1.15-bone-rt-r18
-rw-r--r--.  1 root root 3371694 Jan 21 21:22 System.map-4.1.15-ti-rt-r43
drwxr-xr-x.  2 root root    4096 Jan 24 23:38 uboot
-rw-r--r--.  1 root root    1652 Jul 11 18:04 uEnv.txt
-rwxr-xr-x.  1 root root 6932296 Jan 12  2016 vmlinuz-4.1.15-bone-rt-r18
-rwxr-xr-x.  1 root root 7800752 Jan 21 21:22 vmlinuz-4.1.15-ti-rt-r43
 
So uEnv.txt seems to be updated at the time by the apt-get install, and both the old and new kernel are available. Start of uEnv.txt is:

bash-4.3$ sudo head uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.1.15-bone-rt-r18
#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:
#dtb=am335x-boneblack-emmc-overlay.dtb


But, you mentioned something else, that got me thinking: after backing up the sd card and writing a new image to the sd-card, it failed first pass (no booting BBG whatsever I tried). Flashed the image again, and then my BBG booted. So now I start to suspect my sd card actually. Time for new sd card to make sure. I'll be watching the power supply as well; I'm using a 6600 mAh Lipoly with an Adafruit 500mA Power charge and adapter (if interested: first glimpse of my project page here). I'm not 100% convinced on the power supply as well with occasional drops during booting. So maybe I'l go for micro-usb power supply for "mission critical" changes to the image to ensure correct upgrades and only use the battery when testing the entire setup with stepper drivers and motors. T
Thanks for your suggestions.

Will check john3909's remarks later as well and see if I get the PRU's working with uio/prussdrv.h and the selected kernel.

[William Hermans]

But, you mentioned something else, that got me thinking: after backing up the sd card and writing a new image to the sd-card, it failed first pass (no booting BBG whatsever I tried). Flashed the image again, and then my BBG booted. So now I start to suspect my sd card actually. Time for new sd card to make sure. I'll be watching the power supply as well; I'm using a 6600 mAh Lipoly with an Adafruit 500mA Power charge and adapter (if interested: first glimpse of my project page here). I'm not 100% convinced on the power supply as well with occasional drops during booting. So maybe I'l go for micro-usb power supply for "mission critical" changes to the image to ensure correct upgrades and only use the battery when testing the entire setup with stepper drivers and motors. T
Thanks for your suggestions.

Ok, so here is one thing to consider. After writing a new image to sdcard, and inserting into the beaglebone. Keep in mind that if it's been sitting a while. You may have to press reset a time or two. I believe I remember Gerald saying that sometimes if the board power supply caps are completely without charge. There may be the occasional glitch. I've also experienced this, and  what I do is completely disconnect the board from everything ( especially serial debug ), and then try again. A good indication that you're having a power glitch is when the power LED either does not come on, or come on then goes off again.

Also be aware that if you're using a battery, and you need USB for anything. Once PWR_GOOD( 5v input ) goes away you're going to need to shutdown until the power comes back, or reboot in case of a quick power line glitch.

 The Debian package "acpid" will shut the board down immediately( but cleanly ) from either a PWR_GOOD, or PWR_BTN press interrupt from the PMIC . . . They both trigger the same irq.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/03ba76ad-1d89-4c0d-877c-23f52b6dcdc7%40googlegroups.com.

[Joseph Heller]

Sorry for any confusion, but I'd like to use uio 

[Joseph Heller]

Did not get uio driver up and running yet, is this still an issue on the 4.4 kernel? I did not see a confirmation reading this post either. Tried both loading via device tree (uio_pruss_enable) or plain insmod uio_pruss. 

I wonder if using a 4.1 kernel a safer bet in that respect?

[John Syne]

You still have to follow Roberts instructions I provided you earlier in this thread. Robert didn’t use overlays because Remoteproc had an issue, so if you want to use uio_pruss, you still have to use the same instructions. This applies to the 4.4-ti kernel.

Regards,

John

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/a8f3c97d-28f9-4e0f-8c5f-fb5dbd1503cc%40googlegroups.com.

[Joseph Heller]

That sound like choosing either:

"Robert didn’t use overlays"

or

"all you need to do is load the PRU overlay file to get uio_pruss working"

Not done here yet with trying both options, but took me a day so far stretching my patience in reality.

--> Is there a kernel or preferably an image that's working right away with uio_pruss?

I see some discussion in another post with Robert explains that ti started working on remoteproc somewhere around 4.1 kernels. So I hope actually to save time with an off-the-shelve alternative around that period with uio being the standard, so question here is if there's an advice along that path?

[William Hermans]

I was going to look into this yesterday, but did not for personal reasons. Anyway, no idea whom you're speaking to( I do not see all posts on this group ), but it does not matter what Robert demonstrated. From the information given fro Robert's post. It's clear to at least me that uio_pruss is supposed to have zero issues working, it just needs to be "hooked up".

So, unless this person you're speaking to can show you exactly how to set up uio_pruss on the newer TI kernels . . . Then just ignore that person, as he / she has no idea what they're talking about.

I should have time today to test this myself and it won't take all day. Maybe an hour.

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/8024d3c1-9ce9-41e0-bb82-4bd16a8eb1b8%40googlegroups.com.

[Joseph Heller]

Hi William, thanks for the support, some input got me further at least. This is how far I got today: I now have the uio driver more or less enabled on 4.1.5-ti-rt-r10 via my DTS file: 

/dts-v1/;

/plugin/;

/ { compatible = "ti,beaglebone", "ti,beaglebone-black";

    part-number = "OMNI-ROBOT";

    version = "00A0";       

    

    fragment@0 {

        target = <&am33xx_pinmux>;

        __overlay__ {

            pinctrl_generated: RNS_Generated_Pins {

                pinctrl-single,pins = <

                    0x078 0x07 /* P9_12 OUTPUT | MODE7 */ 

                    0x048 0x07 /* P9_14 OUTPUT | MODE7 */

                    0x04c 0x07 /* P9_16 OUTPUT | MODE7 */

                    0x084 0x07 /* P8_20 OUTPUT | MODE7 */ 

                    0x014 0x07 /* P8_22 OUTPUT | MODE7 */

                    0x004 0x07 /* P8_24 OUTPUT | MODE7 */

                    0x07c 0x07 /* P8_26 OUTPUT | MODE7 */

                    0x018 0x37 /* P8_3 INPUT | MODE7 */

                    0x01c 0x37 /* P8_4 INPUT | MODE7 */

                    0x008 0x37 /* P8_5 INPUT | MODE7 */

                    0x00c 0x37 /* P8_6 INPUT | MODE7 */

                    0x034 0x37 /* P8_11 INPUT | MODE7 */

                    0x030 0x37 /* P8_12 INPUT | MODE7 */

                    0x1ac 0x07 /* P9_25 OUTPUT | MODE7 */

                    0x1a4 0x07 /* P9_27 OUTPUT | MODE7 */

                    0x19c 0x07 /* P9_28 OUTPUT | MODE7 */

                    0x194 0x07 /* P9_29 OUTPUT | MODE7 */

                    0x198 0x07 /* P9_30 OUTPUT | MODE7 */

                    0x190 0x07 /* P9_31 OUTPUT | MODE7 */

                >;

            };

            pru_pru_pins: pinmux_pru_pru_pins {

                pinctrl-single,pins = <

                    0x0a4 0x25 /* P8_46 OUTPUT | MODE 5 */

                >;

            };

        };

    };

    fragment@1 {

        target = <&ocp>;

        __overlay__ {

    pinctrl_generated_pinmux {

              compatible = "bone-pinmux-helper";

               pinctrl-names = "default";

               pinctrl-0 = <&pinctrl_generated>;

               status = "okay";

            };

        };

    };

    fragment@2 {

        target = <&pruss>; 

        __overlay__ { 

            status = "okay"; 

            pinctrl-names = "default";

            pinctrl-0 = <&pru_pru_pins>;

        }; 

    }; 

};

I've some issue now do correct pinmuxing AND have my loader program not fail which it currently here: 

 prussdrv_init();  

 if (prussdrv_open(PRU_EVTOUT_0) == -1) {  

  printf("prussdrv_open() failed\n");  

  return 1;  

 }  

With this example dts above I'm setting p8_46 to mode 0x25 successfully, but I find this in my dmesg now (and guess it's not good): 

pruss_uio 4a300000.pruss: No children

Which still needs some work to figure out. Might give one of the later kernels a try, or something else. I think I'm nearly there though. 

Thanks - Joseph. 

[Robert Nelson]

On Jul 16, 2016 11:57 AM, "Joseph Heller" <joseph.h...@gmail.com> wrote:
>
> Hi William, thanks for the support, some input got me further at least. This is how far I got today: I now have the uio driver more or less enabled on 4.1.5-ti-rt-r10 via my DTS file: 

I thought i was very explicit in my email, 4.4.x-ti r34 or later. For that specific kernel you are using, you'll be discovering the uoi patch in r34. 😉

Regards,

[William Hermans]

@Robert, I do not think he cares specifically about the TI kernel using uio_pruss, he was just experimenting with it. But anyway, I'm testing your instructions now, and will probably go about it slightly different than how you explained . . . but you know how I am. exact steps how to will follow.

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhcEYd2tgc_s3aD%2Bdvz19y24miWqNCrxpahGsw5vryZuA%40mail.gmail.com.

[William Hermans]

heh, ok back on "the job". I keep getting interrupted today . . .

[William Hermans]

I decided to follow Roberts instructions exactly. As I'm not a device tree overlay guru, and I'd have to fool around with the dtsi file, convert it into an overlay file, add a fragment . . . and asI said I'm no guru with that so. A project for a different time.

Currently though I'm in the middle of downloading the dtb rebuilder git . .

[John Syne]

Hi Joseph,

As I said before, Robert wasn’t able to get Remoteproc working using devicetree overlays, so he provided instructions on how to modify the devicetree and then use dtb-rebuilder to create dtbo file. The default is to have neither Remoteproc nor uio_pruss installed because most users don’t use PRU. Once you have a custom dtbo file created, you can use that with kernels > 4.4-ti. Robert did manage to get the uio_pruss overlay to work, but since the remoteproc overlay had issues, better to stay with the standard method and use the dtb-rebuilder and blacklist method. 

Here are Robert’s original instructions:

You can swap between rproc and uio for the pruss...

while, uio can be loaded as an overlay, rproc was failing, so we need
to use the dtb-rebuilder...

Step 1:

upgrade to r34 and reboot:

http://elinux.org/Beagleboard:BeagleBoneBlack_Debian#4.4.x-ti

Step 2:

Install dtb-rebuilder:

git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder
dtb-4.4-ti --depth=1
cd ./dtb-4.4-ti/

Step 3: (rproc)

Edit your device tree:

https://github.com/RobertCNelson/dtb-rebuilder/blob/4.4-ti/src/arm/am335x-bonegreen.dts#L16-L22

nano src/arm/am335x-bonegreen.dts

Change:
/* #include "am33xx-pruss-rproc.dtsi" */ -> #include "am33xx-pruss-rproc.dtsi"
make ; sudo make install

set blacklist:

cat /etc/modprobe.d/pruss-blacklist.conf

blacklist uio_pruss

and reboot..

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c19dc4d6-a86d-4300-aa38-f6ffa3e4385c%40googlegroups.com.

[John Syne]

BTW, if you want to use 4.1 kernel, then use 4.1-bone for uio_pruss and 4.1-ti for remoteproc.

Regards,

John

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/c19dc4d6-a86d-4300-aa38-f6ffa3e4385c%40googlegroups.com.

[William Hermans]

Robert.

You instructions here: https://groups.google.com/forum/#!searchin/beagleboard/Robert$20Nelson$20r34%7Csort:date/beagleboard/l59Dx8ygxNg/GhdRzR7IDAAJ do not work.

I do not what to tell you other than I followed you instructions to the "T" and . . .

william@beaglebone:~$ lsmod |grep uio
uio_pdrv_genirq         3661  0
uio                     8776  1 uio_pdrv_genirq

william@beaglebone:~$ uname -r
4.4.14-ti-rt-r34

william@beaglebone:~$ cat /etc/dogtag
BeagleBoard.org Debian Image 2016-05-01

william@beaglebone:~/dev/dtb-4.4-ti$ grep "#include" src/arm/am335x-boneblack-emmc-overlay.dts
#include "am33xx.dtsi"
#include "am335x-bone-common.dtsi"
#include "am33xx-overlay-edma-fix.dtsi"
/* #include "am33xx-pruss-rproc.dtsi" */
#include "am33xx-pruss-uio.dtsi"

On Sat, Jul 16, 2016 at 10:22 AM, Robert Nelson <robert...@gmail.com> wrote:

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYhcEYd2tgc_s3aD%2Bdvz19y24miWqNCrxpahGsw5vryZuA%40mail.gmail.com.

[William Hermans]

Right, and  . . .

william@beaglebone:~/dev/dtb-4.4-ti$ head /boot/uEnv.txt
#Docs: http://elinux.org/Beagleboard:U-boot_partitioning_layout_2.0

uname_r=4.4.14-ti-rt-r34

#uuid=
#dtb=

##BeagleBone Black/Green dtb's for v4.1.x (BeagleBone White just works..)

##BeagleBone Black: HDMI (Audio/Video) disabled:

dtb=am335x-boneblack-emmc-overlay.dtb

[William Hermans]

RT kernel strikes again apparently . . .

william@beaglebone:~/dev/dtb-4.4-ti$ sudo apt-get install linux-image-4.4.14-ti-r34
william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot

william@beaglebone:~$ uname -r
4.4.14-ti-r34

william@beaglebone:~$ cd dev/dtb-4.4-ti/
william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install
william@beaglebone:~/dev/dtb-4.4-ti$ sudo reboot

william@beaglebone:~$ lsmod |grep  uio

uio_pruss               4928  0
uio_pdrv_genirq         3539  0
uio                     8822  2 uio_pruss,uio_pdrv_genirq

[William Hermans]

So apparently you got bit by the rt kernel bug as many have in the past. So, if you want to use uio_pruss right now with TI's most recently kernel. You're going to have to opt out of using an rt kernel. Which honestly is not a huge deal.

[Joseph Heller]

ok thanks William for the heads-up. Did a check on 4.1.5-ti-r10, so the non-rt version, but no luck yet (but not out of options). Had one failure again truing to apt-get install a 4.1.5 bone15 kernel, so need to try that as well. I missed Robert's remark though earlier in the post to use 4.4.x-ti r34 or later and would like to try that as well. 

---> So to clarify, best bet is to use 4.4.x-ti r34, the non-rt version, in order to use uio_pruss? 

[Joseph Heller]

small progress here; 

4.4.x-ti r34 did not result in any good (only remoteproc as far as I could tell), no uio. 

Therefore went for the bone version, non -rt:

cd /opt/scripts/tools/

sudo git pull

sudo ./update_kernel.sh --bone-kernel --lts-4_4

which gave me 

kernel 4.4.15-bone11

and a new dmesg after loading my dtbo: 

[Mon Jul 18 19:44:48 2016] pruss_uio 4a300000.pruss: pins are not configured from the driver

[Mon Jul 18 19:44:49 2016] bone-pinmux-helper ocp:pinctrl_generated_pinmux: could not find pctdev for node /ocp/interrupt-controller@48200000, deferring probe

Probably the pro loader does not work yet because of this, and quits with prussdrv_open() failed

So I think I need to figure out a bit of my device tree to get the correct pinmuxing / overlay file now. 

[Robert Nelson]

On Mon, Jul 18, 2016 at 3:08 PM, Joseph Heller <joseph.h...@gmail.com> wrote:

small progress here; 

4.4.x-ti r34 did not result in any good (only remoteproc as far as I could tell), no uio. 

Therefore went for the bone version, non -rt:

cd /opt/scripts/tools/

sudo git pull

sudo ./update_kernel.sh --bone-kernel --lts-4_4

which gave me 

kernel 4.4.15-bone11

and a new dmesg after loading my dtbo: 

[Mon Jul 18 19:44:48 2016] pruss_uio 4a300000.pruss: pins are not configured from the driver

[Mon Jul 18 19:44:49 2016] bone-pinmux-helper ocp:pinctrl_generated_pinmux: could not find pctdev for node /ocp/interrupt-controller@48200000, deferring probe

^ looks like you aren't using the dtc compiler for v4.1.x+ targets..

Regards,

--

Robert Nelson
https://rcn-ee.com/

[William Hermans]

Well, not to mention you installed a *bone* kernel anyhow. So what we're talking about is really moot. e.g. a topic for a different discussion.

So. . . back on topic . . .

Download suitable linu image and reboot:
william@beaglebone:~$ sudo apt-get install linux-image-4.4.14-ti-r34
william@beaglebone:~$ sudo reboot

Install git and check your dtc version:
william@beaglebone:~$ sudo apt-get install git
william@beaglebone:~$ dtc -v
Version: DTC 1.4.1

Clone the git into a suitable location:
william@beaglebone:~$ cd dev

git clone -b 4.4-ti https://github.com/RobertCNelson/dtb-rebuilder dtb-4.4-ti --depth=1

william@beaglebone:~/dev$ cd dtb-4.4-ti/

Edit the needed board file( this will be different for every situation )
william@beaglebone:~/dev/dtb-4.4-ti$ nano src/arm/am335x-boneblack-emmc-overlay.dts
change:
/* #include "am33xx-pruss-uio.dtsi" */
to:
#include "am33xx-pruss-uio.dtsi"

Build from source, and install the board file:
william@beaglebone:~/dev/dtb-4.4-ti$ make

william@beaglebone:~/dev/dtb-4.4-ti$ sudo make install

Blacklist the remoteproc drivers:
william@beaglebone:~/dev/dtb-rebuilder$ sudo nano /etc/modprobe.d/pruss-blacklist.conf
blacklist pruss
blacklist pruss_intc
blacklist pru-rproc
william@beaglebone:~/dev$ sudo reboot

Test to see if the device tree file loaded successfully:

william@beaglebone:~$ lsmod |grep  uio
uio_pruss               4928  0
uio_pdrv_genirq         3539  0
uio                     8822  2 uio_pruss,uio_pdrv_genirq

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYgfQYcKT89EihmpdnORK%3D7t9M3zG7gG1SozLtQpaTtQJA%40mail.gmail.com.

[Joseph Heller]

Finally, that worked William (&John &Robert)! I did a small check with an LED and am able to with it on/off now via the PRU and uio. 

For your consideration, I wonder how you feel like to document this more structurally so others can benefit from it? I was offset by some older posts on the forum. Next thing I just though about is to make more use of the .deb functionality instead of relying on script or instructions. For instance uio "conflicts" with remoteproc in reality, but both reside on the same sd-card image. Otherwise, I also understood the PRU's are not that much used, so maybe it;s not worth the effort to invest in this.

Anyway, thanks again for the help, I'd be glad to inform/post the end result of my project somewhere once my time-critical part of c code as transferred to the PRU. 

[Robert Nelson]

Hi Joseph,

On Tue, Jul 19, 2016 at 11:52 AM, Joseph Heller <joseph.h...@gmail.com> wrote:

Finally, that worked William (&John &Robert)! I did a small check with an LED and am able to with it on/off now via the PRU and uio. 

For your consideration, I wonder how you feel like to document this more structurally so others can benefit from it? I was offset by some older posts on the forum. Next thing I just though about is to make more use of the .deb functionality instead of relying on script or instructions. For instance uio "conflicts" with remoteproc in reality, but both reside on the same sd-card image. Otherwise, I also understood the PRU's are not that much used, so maybe it;s not worth the effort to invest in this.

Anyway, thanks again for the help, I'd be glad to inform/post the end result of my project somewhere once my time-critical part of c code as transferred to the PRU. 

So i'm hoping, this will only be short term.  I believe everyone at ti, now has a crystal clear idea of what users want from the pruss interface.  So hopefully this uio/remoteproc will get fixed..  A couple notes on the script, normally the dtb-rebuilder repo can be found here:

/opt/source/dtb-4.4-ti/

It's just for a few releases, that didn't get cloned properly.

 

Regards,

[William Hermans]

I think it's pretty well documented here. However you could always write up an eLinux or whatever wiki page . . . I do have my own web page http://www.embeddedhobbyist.com/ with stuff on it that is important to me. But this information for using UIO on TI kernels I feel is largely useless. Because

The method for enabling either / or will likely change in the future.

Right now, personally I'm still favoring *bone* kernels, and I know I'm not alone.

This is really a trivial "fix". Or something that is really easy to remember how to do.

@Robert, any idea on if TI plans on cleaning up the kernel module mess that now "infests" TI kernels ? using something like 50M + memory needlessly . . .

 

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/1a79bfd0-ddcf-4f32-a6af-95635e067fef%40googlegroups.com.

[Robert Nelson]

On Tue, Jul 19, 2016 at 12:06 PM, William Hermans <yyr...@gmail.com> wrote:

I think it's pretty well documented here. However you could always write up an eLinux or whatever wiki page . . . I do have my own web page http://www.embeddedhobbyist.com/ with stuff on it that is important to me. But this information for using UIO on TI kernels I feel is largely useless. Because

The method for enabling either / or will likely change in the future.

Right now, personally I'm still favoring *bone* kernels, and I know I'm not alone.

This is really a trivial "fix". Or something that is really easy to remember how to do.

@Robert, any idea on if TI plans on cleaning up the kernel module mess that now "infests" TI kernels ? using something like 50M + memory needlessly . . .

It's... debug_info..

CONFIG_DEBUG_INFO=y

# CONFIG_DEBUG_INFO_REDUCED is not set

CONFIG_DEBUG_INFO_SPLIT=y

CONFIG_DEBUG_INFO_DWARF4=y

"atleast" the zImage isn't bloated, but the modules are 4x/5x bigger...

a few users wanted to use systemtap:

https://wiki.archlinux.org/index.php/SystemTap

that needs debug_info..

Regards,

[William Hermans]

Sorry Robert I did not mean to reply only directly to you . . . but also . . .

a few users wanted to use systemtap:

https://wiki.archlinux.org/index.php/SystemTap

that needs debug_info..

So question about this. Are these few people more important than the rest of the users out here ? Not meant as a smart ass question seriously. I mean if I have to I can always compile my own kernel, but not everyone has the know how.

My idea of of images and kernels for the beaglebone has always been minimal. Nothing wrong with perhaps compiling with modules in mind,  but keeping things standard so people can find out easily how to change these image properly to get where they want to be. But that's my idea . . .

On Tue, Jul 19, 2016 at 10:14 AM, William Hermans <yyr...@gmail.com> wrote:

Hi Robert,

Well I mean this:

william@beaglebone:~$ lsmod
Module                  Size  Used by
xt_REDIRECT             1885  1
nf_nat_redirect         1790  1 xt_REDIRECT
xt_tcpudp               3091  1
iptable_nat             1997  1
nf_conntrack_ipv4      14735  1
nf_defrag_ipv4          1677  1 nf_conntrack_ipv4
nf_nat_ipv4             5392  1 iptable_nat
nf_nat                 15031  2 nf_nat_redirect,nf_nat_ipv4
nf_conntrack           98575  3 nf_nat,nf_nat_ipv4,nf_conntrack_ipv4
ip_tables              11986  1 iptable_nat
x_tables               17435  3 ip_tables,xt_tcpudp,xt_REDIRECT
rpcsec_gss_krb5        23814  0
nfsd                  261377  2
spidev                  7523  0
omap_aes_driver        19045  0
omap_sham              21340  0
uio_pruss               4928  0
omap_rng                4423  0
rng_core                7703  1 omap_rng
pwm_tiehrpwm            4706  0
pwm_tiecap              3652  0
tieqep                  8758  0
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  0

uio_pdrv_genirq         3539  0
uio                     8822  2 uio_pruss,uio_pdrv_genirq

Lots of stuff that really does not need to be loaded. That, and I'm not quite sure how these modules are loaded, and what's the best way to remove them. The fixes I have here: https://github.com/wphermans/bbb-cleanup I feel are hackish, and maybe somehow incomplete . . .

[William Hermans]

Ah those! most of them come from loading the cape overlay... (cape_universal=enable)

Regards,

Seriously ? Wow I had no idea. Is this a requirement, or can it be changed ?  Or . . .hmmm how could one modify this behavior so that only what's needed is loaded. Other than my hackish fix. Or, do we need cape_universal=enable to use universal-io ? I honestly have not experimented with disabling cape_universal and temptation to use universal IO.

On Tue, Jul 19, 2016 at 10:17 AM, Robert Nelson <robert...@gmail.com> wrote:

evdev                  10695  0

uio_pdrv_genirq         3539  0
uio                     8822  2 uio_pruss,uio_pdrv_genirq

Lots of stuff that really does not need to be loaded. That, and I'm not quite sure how these modules are loaded, and what's the best way to remove them. The fixes I have here: https://github.com/wphermans/bbb-cleanup I feel are hackish, and maybe somehow incomplete . . .

Ah those! most of them come from loading the cape overlay... (cape_universal=enable)

Regards,

[William Hermans]

temptation <--- wtf did that come from . . . dahm spell checker lol. attemtping . . .

[Robert Nelson]

On Tue, Jul 19, 2016 at 12:24 PM, William Hermans <yyr...@gmail.com> wrote:

Ah those! most of them come from loading the cape overlay... (cape_universal=enable)

Regards,

Seriously ? Wow I had no idea. Is this a requirement, or can it be changed ?  Or . . .hmmm how could one modify this behavior so that only what's needed is loaded. Other than my hackish fix. Or, do we need cape_universal=enable to use universal-io ? I honestly have not experimented with disabling cape_universal and temptation to use universal IO.

So the cape_universal=enable, is just to hook to more easily disable/enable universal-io at bootup.

But yeah, what universal-io does, "everything" inside the chip get's enabled, except for the pinmux-ing..  Which you control (the pinmuxing) in userspace..

It's more reliable then loading/unloading individual peripherals, but it has a different cost (memory and possiblly power)

Regards,

[William Hermans]

Ok, thanks Robert. I am really starting to warm up to universal-io. Never had the chance, or reason to get it working before. Now . . . I'm using it to test custom cape circuits, and all kind of things.

Plus I really do want to write that webpage GPIO / peripheral configuration page . . . but that may still be a while yet. Still have many other priorities . . . and much if it has nothing to do with computers. Unfortunately.

[John Syne]

Hi Robert,

I was one of those users who uses Systemtap, but I always build my own kernel with debug symbols enabled, so I would recommend a standard kernel version without debug symbols and if you are up to it, add another build with a -dbg.deb kernel/modules version. Regarding the other kernel modules such as pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add these to the blacklist and have users remove those from the blacklist if they want these drivers available?

 

Regards,

John

--
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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYiME9UPiBLcQyJ7UnMxK%2Bmz%3DWXVVWZWPBRxqabg%2B--YjA%40mail.gmail.com.

[Robert Nelson]

On Tue, Jul 19, 2016 at 1:56 PM, John Syne <john...@gmail.com> wrote:

Hi Robert,

I was one of those users who uses Systemtap, but I always build my own kernel with debug symbols enabled, so I would recommend a standard kernel version without debug symbols and if you are up to it, add another build with a -dbg.deb kernel/modules version. Regarding the other kernel modules such as pwn, spidev, snd*(no audio on base BBB), c-can, etc, why not add these to the blacklist and have users remove those from the blacklist if they want these drivers available?

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,

[William Hermans]

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. . .

 

--

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...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/CAOCHtYi-EJTZ6UVdXOpyKvrjhwksKqd3YFeXjPQsZz9FFUpEZg%40mail.gmail.com.

[Joseph Heller]

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

[Joseph Heller]

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

[William Hermans]

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.

To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/291a26c9-f393-46ea-af07-0df3e2ac99c7%40googlegroups.com.