Moving Beaglebone Build to Newer Linux Release

[Wackerbarth]

The instructions and code for the BBB are based on Debian "Jesse". However, the current release is 'Stretch" and not all of the parts to build from the older release remain available.

In the conversion, the Linux kernel has been upgraded and the SPI bus designation has changed.

Currently, this bus designation is defined as a constant in extras/replicape.py code.

REPLICAPE_SHIFT_REGISTER_BUS = "spidev1.1"

This was correct for the jessie kernel, but needs to be changed to

REPLICAPE_SHIFT_REGISTER_BUS = "spidev2.1"

when upgrading to the kernel used in the stretch release.

How do you wish to handle the distinction which is caused by the different kernels?

[klipper-gitissuebot]

Hi @Wackerbarth,

It did not look like there was a Klipper log file attached to this ticket. The log file has been engineered to answer common questions the Klipper developers have about the software and its environment (software version, hardware type, configuration, event timing, and hundreds of other questions).

Unfortunately, too many people have opened tickets without providing the log. That consumes developer time; time that would be better spent enhancing the software. If this ticket references an event that has occurred while running the software then the Klipper log must be attached to this ticket. Otherwise, this ticket will be automatically closed in a few days.

For information on obtaining the Klipper log file see: https://github.com/KevinOConnor/klipper/blob/master/docs/Contact.md

The log can still be attached to this ticket - just add a comment and attach the log to that comment.

Best regards, ~ Your friendly GitIssueBot

PS: I'm just an automated script, not a human being.

[Wackerbarth]

There is no klipper log file because this involves the installation of klipper, not its execution.

[KevinOConnor]

Ideally, there would be some way to autodetect which spi device to use (for example, by looking for a particular file in /sys/).

FWIW, the Linux support on the Beaglebone has been dreadful. It seems that every 4 months there's a non-backwards compatible change. And, it's basically impossible to find any documentation on the changes, mostly because any search gets lost in all their previous non-backwards compatible changes..

-Kevin

[Wackerbarth]

I haven't found anyway to distinguish things other than the version of the OS which differs between my installation and the earlier ones. Is there anyone out there who has a Replicape running on a BBB? If so, please assist me in determining the differences.

Perhaps we should just abandon the "Jessie" builds and update everything to reflect "Stretch" (or even something newer).

FEEDBACK, PLEASE

[jannau]

I'm using Stretch with the 4.4 TI kernel (iirc I had problems with the pru firmware loading on the 4.14 kernel when I updated). So the kernel version would be a better way to identify the spi device than the os version. The device name should be discoverable through /sys/devices/platform/ocp/481a0000.spi/ though.

[Wackerbarth]

@jannau -- Yes, I agree the the critical "value" is the kernel (4.4 vs 4.14) and that is what I use to distinguish the two, particularly because that is the characteristic that python provides. (I must admit that I thought that the kernel version was an integral part of the release distinctions). Our fundamental issue is in obtaining an appropriate "-ti" kernel build.

I'm having no issue with 4.14 kernel after changing the commands to perform the pru install.

But, I still cannot figure out what spi designation I need to specify to the python code based on anything I find in /sys/devices/platform/ocp/481a0000.spi/.

Again, I'm happy supporting multiple kernel versions if we can "automate" the distinction.

But I also think that we should provide an installation procedure that "works" for someone who has no prior version to upgrade.

In the long run, I seriously question the viability of the Replicape since, at this time, there is no source for additional boards and the developer of the board is placing all of his effort on a new "Revolve" board which has significant differences from the BBB ecosystem.

[KevinOConnor]

On my test beaglebone I get:

debian@beaglebone:~$ ls -l /sys/bus/spi/drivers/spidev/
total 0
--w------- 1 root root 4096 Jul 10 16:25 bind
lrwxrwxrwx 1 root root    0 Jul 10 16:25 module -> ../../../../module/spidev
lrwxrwxrwx 1 root root    0 Jul 10 16:25 spi1.0 -> ../../../../devices/platform/ocp/48030000.spi/spi_master/spi1/spi1.0
lrwxrwxrwx 1 root root    0 Jul 10 16:25 spi1.1 -> ../../../../devices/platform/ocp/48030000.spi/spi_master/spi1/spi1.1
lrwxrwxrwx 1 root root    0 Jul 10 16:25 spi2.0 -> ../../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.0
lrwxrwxrwx 1 root root    0 Jul 10 16:25 spi2.1 -> ../../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.1
--w------- 1 root root 4096 Jul 10 16:25 uevent
--w------- 1 root root 4096 Jul 10 16:25 unbind

Presumably, we want the spidev that points to 481a0000.spi?

If so, then the replicape.py code could try to check that (eg, something like if '481a0000' in os.readlink("/sys/bus/spi/drivers/spidev/spi2.1"): default_spidev = 'spidev2.1').

But I also think that we should provide an installation procedure that "works" for someone who has no prior version to upgrade.

If someone wishes to update the instructions (and code) to work with the latest OS release, then that would be great. It would be preferable for the code to be backwards compatible, but if that's not an option then I don't think it is required.

-Kevin

[Wackerbarth]

Kevin -- I agree with the approach that you describe. However, what I don't have available is the corresponding data from an earlier system that required 'spidev1.1'. Without that, it is only a guess whether, or not, some particular code would work in both cases.

So, hopefully someone who is using the current code can supply more details about their kernel and the related "/sys/" space.

WRT documentation, I'll be happy to offer a revision to go along with whatever code changes are developed. (In particular, there are also some changes related to the installation and control of the pru code)

[KevinOConnor]

Perhaps @jakep82 or @blackstump still have access to a beaglebone with an older OS rev. (I don't have a replicape.)

In any case, if the default is spidev1.1 and we only change on confirmation of valid spidev2.1 then I think it should be safe. Something like:

class Replicape:
    def __init__(self, config):
        ...
        default_spidev = "spidev1.1"
        try:
            if (not self.host_mcu.is_fileoutput()
                and '481a0000' in os.readlink("/sys/bus/spi/drivers/spidev/spi2.1")):
                default_spidev = 'spidev2.1'
        except os.error as e:
             pass
        self.sr_spi = bus.MCU_SPI(self.host_mcu, default_spidev,
                                  None, 0, 50000000, self.sr_disabled)

-Kevin

[jannau]

With kernel 4.4.113-ti-r149:

ls -l /sys/bus/spi/drivers/spidev/
total 0
--w------- 1 root root 4096 Jul 10 17:14 bind
lrwxrwxrwx 1 root root    0 Jul 10 17:14 module -> ../../../../module/spidev
lrwxrwxrwx 1 root root    0 Jul 10 17:14 spi1.1 -> ../../../../devices/platform/ocp/481a0000.spi/spi_master/spi1/spi1.1
--w------- 1 root root 4096 Nov  3  2016 uevent
--w------- 1 root root 4096 Jul 10 17:14 unbind

My idea was to use /sys/devices/platform/ocp/481a0000.spi/spi_master/spi?/spi?.? to determine the correct spi device.

[jakep82]

I would still like to get my Replicape running, but I gave up long ago. I never got my bltouch working, however I see some work was done to fix this a few months ago. Perhaps I'll pull it out and try again, but I would prefer to use Stretch with a newer kernel.

[KevinOConnor]

With kernel 4.4.113-ti-r149:

Ah - so it seems you don't have an spidev2.1 at all. What does ls -l /sys/bus/spi/drivers/spidev/ report on the latest kernel (4.14+)? The issue may not be directly due to renumbering, but due to 48030000.spi being registered. In any case, I think the pseudo code in https://github.com/KevinOConnor/klipper/issues/1778#issuecomment-510146382 should fix it.

-Kevin

[Wackerbarth]

Linux ClipperShip 4.14.108-ti-r108 #1 SMP PREEMPT Tue Jun 18 05:11:38 UTC 2019 armv7l GNU/Linux
debian@ClipperShip:~$ ls -l /sys/bus/spi/drivers/spidev/
total 0
--w------- 1 root root 4096 Jul 10 13:46 bind
lrwxrwxrwx 1 root root    0 Jul 10 13:46 module -> ../../../../module/spidev
lrwxrwxrwx 1 root root    0 Jul 10 13:46 spi1.0 -> ../../../../devices/platform/ocp/48030000.spi/spi_master/spi1/spi1.0
lrwxrwxrwx 1 root root    0 Jul 10 13:46 spi1.1 -> ../../../../devices/platform/ocp/48030000.spi/spi_master/spi1/spi1.1
lrwxrwxrwx 1 root root    0 Jul 10 13:46 spi2.0 -> ../../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.0
lrwxrwxrwx 1 root root    0 Jul 10 13:46 spi2.1 -> ../../../../devices/platform/ocp/481a0000.spi/spi_master/spi2/spi2.1
--w------- 1 root root 4096 Jul 10 03:11 uevent
--w------- 1 root root 4096 Jul 10 13:46 unbind
debian@ClipperShip:~$

So, I think that we can merge a pattern as @jannau's suggests with the code @KevinOConnor proposes and not use a "default" as such. If we cannot locate /sys/devices/platform/ocp/481a0000.spi/spi_master/spi?/spi?.1, there are likely to be other issues.

[BlackStump]

I am using debian 9.9 and a image is here https://drive.google.com/open?id=1dem5CAtp8lZpqWwxrfGp3mqNZKJ4gXY7

[BlackStump]

I'm having no issue with 4.14 kernel after changing the commands to perform the pru install.

@Wackerbarth May I ask what commands did you change to get the pru to install on 4.14 kernel I have problems with anything after Debian 9.2

[KevinOConnor]

FYI, commit bc78bc48 should address the original issue reported here.

-Kevin

[jakep82]

@Wackerbarth I'm also curious to know what commands you changed to get 4.14 working. I finally have my Replicape fully functional on Jessie with a 4.4 kernel, but I would prefer to move to something newer. I tried Stretch with 4.14, but ran into issues getting the PRU running.

[BlackStump]

@jakep82 @KevinOConnor I have fudged something that works on 4.14 but it really needs @KevinOConnor to look at and do correctly. unbind bind does not seem to work so in trying to understand what it going on I went to the pru compliers git and noticed he was starting the pru,s with a different command https://github.com/dinuxbg/pru-gcc-examples/blob/master/beaglemic/pru/start.sh#L6

so I changed the pru start script to reflect that change https://github.com/BlackStump/klipper/blob/master/scripts/klipper-pru-start.sh

it works after a fashion but needed a manual restart of the pru,s so I made a service script that delayed the pru start

[Unit] Documentation=man:systemd-sysv-generator(8) SourcePath=/etc/init.d/klipper_pru Description=LSB: Klipper_PRU daemon After=multi-user.target

[Service] Type=forking Restart=no TimeoutSec=5min IgnoreSIGPIPE=no KillMode=process GuessMainPID=no RemainAfterExit=yes SuccessExitStatus=5 6 ExecStart=/etc/init.d/klipper_pru start ExecStop=/etc/init.d/klipper_pru stop ExecReload=/etc/init.d/klipper_pru reload

[Install] WantedBy=multi-user.target

now it works on boot but I feel it is not quite there or done correctly but that is purely a assumption as I am not a programmer, and at 60 years of age probably never going to be one hehe.

[BlackStump]

I made a image with Debian 9.9 console with the changes above, be aware it does not include Octoprint but DWC and it pulls from my git, easy to change back to master. https://drive.google.com/open?id=1dem5CAtp8lZpqWwxrfGp3mqNZKJ4gXY7

[jakep82]

Thanks, but I'll probably just stick with Jessie unless/until the necessary changes are added to the main repo in Klipper. I tested everything last night, and my Replicape is finally 100% functional, including my bltouch. I've owned my Replicape for 29 months, and last night was the first time I made a successful print with everything working.

[KevinOConnor]

Thanks for the links. I'll take a look the next time I get a chance to work on the Beaglebone. It's probably a few months out though. If someone beats me to it and is up for updating the docs, then that would be great.

-Kevin

[KevinOConnor]

I'm going to close this issue as the original issue reported should now be fixed.

-Kevin