rppal: Wrong revision numbers on Fedora

I’ve tried to use the library under Fedora and ran into a simple Error. Fedora does not recognise the revision number correctly and always shows 0000 in /proc/cpuinfo. This leads to an Error::UnkownModel in any case. Currently, I’m on a 3B and I also tested it on a 2B. I’m using a small hack in system.rs line 179 to identify the model manually since I know which version I’m using:

"0000" => Model::RaspberryPi3B,

Maybe there could be an option to configure the model manually.

Here’s the end of my /proc/cpuinfo (it seems that it also gets the SoC wrong):

Hardware:    BCM2835
Revision:    0000
Serial:      00000000e07fdbcc

If you need more information or any help, I’d be glad to help. Cheers!

About this issue

Original URL
State: closed
Created 6 years ago
Comments: 17 (8 by maintainers)

Commits related to this issue

Add additional options to identify Pi model Needed for distributions with inaccurate data in /proc/cpuinfo. See: #7 — committed to golemparts/rppal by golemparts 6 years ago

Most upvoted comments

@KuabeM @drahnr so just for fun, I made a quick proof of concept polling interrupts using the GPIO character device, and added the cdev_gpio_poll_interrupt() method to Gpio to experiment with. It’ll block until the interrupt is triggered. Would either of you mind checking if it works on Fedora, or if it’s bugged like the sysfs interrupts?

extern crate rppal;

use rppal::gpio::{Gpio, Trigger};

fn main() {
    let gpio = Gpio::new().unwrap();
    println!("{:?}", gpio.cdev_gpio_poll_interrupt(27, Trigger::RisingEdge).unwrap());
}

golemparts on Jul 3, 2018

Your prove of concept works just fine on Fedora. I also tried the master branch in our project - no more bugs, everything is running flawless 🎉

KuabeM on Jul 9, 2018

@KuabeM if that works we move back to fedora as soon as that got implemented (:

drahnr on Jul 4, 2018

Awesome. While researching alternatives yesterday, I learned that the sysfs gpio interface has been deprecated, so I would have to replace the existing interrupt code at some point anyway. If it’s also a workaround for the Fedora bug that would be a nice bonus!

I’ll move this to a new issue for more convenient tracking.

golemparts on Jul 4, 2018

@golemparts @KuabeM (<- as promised) added a tracking ticket for GPIO IRQs not working on Fedora https://bugzilla.redhat.com/show_bug.cgi?id=1597577 (proper Fedora, FedBerry might be a differnt story)

drahnr on Jul 3, 2018

Awesome! Thanks for testing. 0.7.0 should be available through crates.io later today.

golemparts on Jun 26, 2018

Indeed. That definitely seems like a good alternative, and makes things a bit easier than dealing with manually setting the model. Thanks for the quick reply with the needed info. Time to dig up some earlier models, and make sure they didn’t change the format at some point like they did with revisions.

This looks like an easy fix, which I should be able to squeeze into the upcoming 0.7.0 release scheduled for this week.

golemparts on Jun 25, 2018

Here you go: On the 3B:

cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 3 Model B% 
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,3-model-bbrcm,bcm2837%

And on the 2B:

cat  /sys/firmware/devicetree/base/model
    Raspberry Pi 2 Model B%  
cat /sys/firmware/devicetree/base/compatible
    raspberrypi,2-model-bbrcm,bcm2836%

That looks not that bad does it?

KuabeM on Jun 25, 2018