Revisiting this subject, I found that in BB-BONE-REPLICAP-0B3A.dts (as it
is presently in
bb.org-overlays) I could completely comment out fragment@2
fragment@2{
target = <&pruss>;
__overlay__{
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <&pruicss_stepper_pins>;
stepper_x{
pin-names = "Replic:pru-step_x", "Replic:pru-dir_x";
gpios = <&gpio0 27 0
&gpio1 29 0>;
......
and add a fragment like
fragment@7 {
target = <&ocp>;
__overlay__ {
bone-replicape {
compatible = "gpio-of-helper";
status = "okay";
pinctrl-names = "default";
pinctrl-0 = <>;
step_x {
gpio-name = "Replic:step_x";
gpio = <&gpio0 27 0>;
output;
};
.....
which exports the stepper output pins driven by the pru stepgen, so that
there is no need
anymore to make a separate export to /sys/class/gpio.
This works on Debian Stretch with kernel 4.14.25-ti-rt-r38.
Is there a reason why the original overlay apparently worked with earlier
kernel versions?
For example, in
https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Replicape
there is no separate export of the stepper output pins, so that was
apparently done by the overlay.
The version adapted to Debian Stretch
<https://github.com/machinekit/machinekit/tree/master/configs/ARM/BeagleBone/Replicape-Stretch>
using the original overlay had to export the pins separately.
I do not really feel qualified to actually suggest to modify the Replicape
overlay in bb.org-overlays.
Maybe the experts can comment.
Am Montag, 19. Februar 2018 21:39:49 UTC+1 schrieb Karl Jacobs:
>
> hmm... no luck yet.
> Of course I could live with a script doing the echo "$GPIONR" >
> /sys/class/gpio/export etc. for all pru output pins, but I'd rather
> like to know what is going on.
>
> The thing is that on a 4.9.81-bone-rt-r9 kernel on jessie the exact same
> thing happens, pru does not toggle
> the GPIO outputs, everything else works. This kernel still uses the slots
> file,so I can confirm that the overlay is actually loaded:
> cat /sys/devices/platform/bone_capemgr/slots
> 0: P---L- 0 Replicape 3D printer cape,0B3A,Intelligent
> Agen,BB-BONE-REPLICAP
> 1: PF---- -1
> 2: PF---- -1
> 3: PF---- -1
>
> There are no pin conflicts in dmesg (attached).
>
> In his configuration at https://github.com/sam0737/machinekit-replicape
> Sam Wong mentions that it was tested on a 4.8 kernel which seems not to be
> around anymore. I find it hard to believe that things broke for kernel
> 4.9. What irritates me though is that in his readme, his slots file shows
> that
> he apparently had cape-universaln loaded (but replicape only probed and
> not loaded)
>
> 0: P----- -1 Replicape 3D printer cape,0B3A,Intelligent
> Agen,BB-BONE-REPLICAP
> 1: PF---- -1
> 2: PF---- -1
> 3: PF---- -1
> 4: P-O-L- 0 Override Board Name,00A0,Override Manuf,cape-universaln
>
> When I try to load cape-universaln, dmesg reports pin conflicts because
> cape-universaln essentially takes over all pins
> and the load fails, as I would have expected.
>
> To my understanding and citing Charles' comments in a "setup.sh", used in
> several machinekit beaglebone configs:
>
> # Any GPIO pins driven by the PRU need to have their direction set properly
> # here. The PRU does not do any setup of the GPIO, it just yanks on the
> # pins and assumes you have the output enables configured already
>
> That is done with cape-universal and config-pin in setup.sh, as far as I
> understand, and I know it of course works because that is what
> happily drives my small "machinekit-beaglebone" (3.8 kernel) CNC lathe
> since a few years.
>
> If the cape has its own overlay, my understanding is that the
> corresponding device tree blob, loaded either with bone-capemgr or uboot,
> takes care of setting the GPIO pin direction for the pru outputs. As far
> as I understand, exactly that is contained in fragment@0
> and fragment@2 of bb.org-overlays/src/arm/BB-BONE-REPLICAP-00B3.dts
> I might be completely off here, so if anybody could point me to a document
> describing what actually happens when the dtbo is loaded, that would be
> appreciated. It might be way over my head, though, as I'm not a
> professional software engineer.
> Regards,
> Karl
>
> Am Sonntag, 18. Februar 2018 00:56:33 UTC+1 schrieb Karl Jacobs:
>>
>> The fact that cat /sys/kernel/debug/pinctrl/44e10800.pinmux/pingroups
>> among others shows
>>
>> group: pinmux_replicape_spi1_pins
>> pin 100 (PIN100)
>> pin 101 (PIN101)
>> pin 102 (PIN102)
>> pin 89 (PIN89)
>>
>> and
>> group: pinmux_pruicss_stepper_pins
>> pin 14 (PIN14)
>> pin 15 (PIN15)
>> pin 10 (PIN10)
>> pin 11 (PIN11)
>> pin 13 (PIN13)
>> pin 12 (PIN12)
>> pin 9 (PIN9)
>> pin 8 (PIN8)
>> pin 31 (PIN31)
>> pin 30 (PIN30)
>>
>> makes me believe that the cape is actually loaded, but I might be wrong.
>> The full dmesg does not show anything like "REPLICAP" anywhere else but on
>> the lines that are contained in my uploaded file. Actually I haven't found
>> a hint anywhere where to look for an actual version of the loaded cape in
>> the "slotless" uboot-overlays. The original sam0737 code looks for that in
>> the slots file to decide between two different Replicape board versions. I
>> hardcoded the board version to 0B3A.
>>
>> I also could not find any hint for the overlay in the /proc/device-tree
>> although I have to admit that I wouldn't know for what to look exactly. Am
>> I mistaken to assume that the overlay file is loaded if all other functions
>> like temperature readings, endstops are working, spi init works, setting
>> motor current (needs spi) does not give error messages?
>>
>> Commenting the uboot_overlay_pru line in uEnv.txt + reboot did not change
>> anything.
>> cat /sys/class/uio/uio0/name still shows pruss_evt0 as expected and the
>> pru works as before when I manually set the output pin. It seems that the
>> uio pruss is the default.
>> Setting uboot_overlay_addr0=/lib/firmware/BB-BONE-REPLICAP-0B3A.dtbo in
>> uEnv,txt also shows no difference (it does if you misspell the filename:
>> BBB does not complete the boot in that case).
>> Regards,
>> Karl
>>
>> Am Samstag, 17. Februar 2018 20:14:06 UTC+1 schrieb Charles Steinkuehler:
>>>
>>> On 2/17/2018 3:18 AM, Karl Jacobs wrote:
>>> >
>>> > The BB-BONE-REPLICAP-0B3A.dtbo is loaded via u-boot load as you can
>>> see
>>> > from the attached file
>>> > giving the details on version.sh, dmesg and uEnv , where you can see
>>> that I
>>> > disabled HDMI, EMMC and
>>> > cape-universal.
>>>
>>> I see that the Replicape was detected, but not that it's overlay was
>>> loaded. I think you need to manually load the overlay with U-Boot, or
>>> possibly copy the overlay somewhere U-Boot can access it and it might
>>> get loaded automatically (I'm not sure which, I haven't worked much
>>> with the U-Boot overlays).
>>>
>>> You can verify if the replicape overlay was actually applied by
>>> browsing through the active device-tree (/proc/device-tree/...)
>>> regardless of how the overlay was loaded and by examining the *FULL*
>>> output of dmesg if the kernel loaded the overlay.
>>>
>>> Your problem could also be that you're trying to load the pruss driver
>>> using "uboot_overlay_pru=", but the Replicape overlay is also enabling
>>> the PRU and the PRU driven pins are exported in the same overlay
>>> stanza that enables the PRU:
>>>
>>>
>>> https://github.com/beagleboard/bb.org-overlays/blob/master/src/arm/BB-BONE-REPLICAP-0B3A.dts#L137-L142
>>>
>>>
>>> Try commenting the uboot_overlay_pru line in your uenv.txt file and
>>> see if that helps.
>>>
>>> --
>>> Charles Steinkuehler
>>> cha...@steinkuehler.net
>>>
>>
--
website: http://www.machinekit.io blog: http://blog.machinekit.io github:
https://github.com/machinekit
---
You received this message because you are subscribed to the Google Groups
"Machinekit" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to machinekit+unsubscr...@googlegroups.com.
Visit this group at https://groups.google.com/group/machinekit.
For more options, visit https://groups.google.com/d/optout.
