Support for hwver 0xa01040, Pi 2 pre-release & device-tree auto-detection

[Gadgetoid]

This PR includes:

• Support for hwver 0x14 - Compute Module
• Support for hwver 0xa01040 - Pre-release Raspberry Pi 2
• Attempt to get details from device-tree before falling back on hwver matching

Included for posterity:

This PR adds support for a rare, pre-release Pi 2 edition. It also highlights the need for a more robust way of grabbing these offsets, with this method as the fallback. It can be done via the device-tree, at least half of the puzzle anyway.

For the peripheral offset RPi.GPIO uses:

    if ((fp = fopen("/proc/device-tree/soc/ranges", "rb")) != NULL) {
        // get peri base from device tree
        fseek(fp, 4, SEEK_SET);
        if (fread(buf, 1, sizeof buf, fp) == sizeof buf) {
            peri_base = buf[0] << 24 | buf[1] << 16 | buf[2] << 8 | buf[3] << 0;
        }
        fclose(fp);
    } else {

[Gadgetoid]

As discussed in #105 I've revised this PR with code to auto-detect the Videocore and Peripheral base address from the relevant locations in device-tree. This should mean more robust support for presently unknown versions of the Pi.

[jgarff]

Thanks for the pull request. One quick question however, how does this work on non-raspberry pis? I quite often get issues reported where the user thinks the library will work on a orange pi or some other non-broadcom based clone. I just want to make sure that the library will fail appropriately without a segfault or some weird failure. I'm also concerned that if broadcom releases a non-compatible chipset, this will also cause crashes. Having the explicit table, while a pain, is intended to protect against this. Thanks.

[Gadgetoid]

Aha! Now that you've explained it, I totally understand the reasoning behind an explicit device file. Presumably any version of the Pi not explicitly tested- a new chip is a good example- could potentially cause problems if it doesn't behave how you might expect.

The short answer is: I don't know. Adding auto-detection means it will potentially try to run on as of yet unreleased new Pi hardware, skipping the device detection failure and potentially trying to set up PWM hardware that doesn't exist, etc.

I'm happy to concede that the small benefit that auto-detect brings to the table could easily be outweighed by the probably larger chance of a breaking change to future hardware.

I'm happy to drop this and submit a PR for the specific revision of Pi that I found and tested recently.

More explicit error messages should also ease the discovery and addition of new Pi's, too!

You're certainly not alone with receiving issues about code designed for the Pi not running on the Orange Pi, Banana Pi, etc ;D

[jgarff]

I've already added the new table entries to the mainline in change 7d47edc. I wanted to get these in as soon as possible. I didn't do a merge due to the device tree changeset. I made sure to give you credit in the commit message. Would you mind pulling and testing to make sure they work? I really appreciate your fixes, and I'm definitely open to ideas on how to solve the problem while making sure to maintain compatibility and a safe failure mechanism. Thanks.

[Gadgetoid]

Sure thing, sorry for the delay- so many miscellaneous concerns that I can't keep on top of it all! I'm not worried about credit, only worried about making sure you get these new device IDs ASAP!