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

GoogleGroups
1

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?)

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

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

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

4

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.

5

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

6

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.

7

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

8

Well, I used apt-get install. I traced back the command entered when examining .bash_history:

9

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.

10

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.

11

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

12

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?

13

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

14

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?

15

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.

16

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.

17

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

Regards,

18

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

19

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

20

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