fix support for recent pi models (Zero W etc) #100
Conversation
. Fix Raspberry Pi model detection . Add model detection in GPIO module . Try to fix mailbox char device detection on various kernels . Fix compiler warnings
. Distinguish board revision from CPU model. . Consider the board revision to be 3 (latest) by default. . Use the CPU model (and not the board revision) to determine the GPIO base address. . Use the board revision to determine which pin/gpio mappings to use. . Fix the pin to gpio mapping definition for revision 3 boards. . Add all known models (according to http://elinux.org/RPi_HardwareHistory) to the MODEL_DATA (sysinfo) definition. . Only use the Pi revision (and no longer the sysinfo string) to determine which GPIO list to use in the Python scripts.
details taken from http://elinux.org/RPi_HardwareHistory
added build recipes for python version 3.3, 3.4, 3.5 and 3.6, include directories may need to be changed if incorrect
|
I've had a chance to test PWM on a pi zero W and somehow it completely locks up the pi, to the point where the console is completely unresponsive and all network traffic is dropped. not even a response to a ping. |
|
ok so the problem is due to the base address used to control the GPIO in the pwm extension. in the main RPIO extension there are two defines for the peri_base address (BCM2708 and 2709) and a static integer to hold the one in use by the pi (depending on model) which is loaded in the call to setup, however this code does not appear in the PWM extension so only the BCM2708 base address is used which is wrong on newer pi models. I've manually changed the value to check that it works with the correct address, so no i will add the detection code. |
the pwm extension was using the default 2708 base address no matter what pi was in use, leading to corrupted memory and freezing the pi. Moved the cpuinfo files into a c_common directory so they can be used by both the RPIO extension and the PWM extension.
|
i have now tested pwm and normal functions on a pi 1B and a zero W at the latest commit level (ee17c8d) and both function normally, in addition when using an oscilloscope the pulses appear to be the right duration and frequency (saw one issue report claiming they were wrong? |
|
can further report that the current method of determining the base memory address is wrong both in the main part of the module and in the original PWM module but in different ways. firstly the main module uses the revision to determine the base address, which on some of my Pi's gave an address of 0x2000000 where it should have given 0x3f00000 (pi 2 & 3) however in the PWM module it was attempting to read the base address from a file in the filesystem, and using 0x2000000 as a fallback (not a bad thing) however the address retrieved from that file ended up wrong and created a handle to memory used for some other purpose, hence modifying it caused a crash. I will attempt to work out why the file system method returns the wrong value (seems to be the suggested best practice?) however if that fails i will look at changing the address detection to something like this |
|
I have tried your v2 fork on Raspberry Pi 3B, but it was giving me an error "error: unknown type name ‘uint32_t’" on 'cpuinfo.h' and 'cpuinfo.c' when I tried to install. |
|
Hi James, My name is Reik Hua, and i downloaded V2 from your respository: https://github.com/JamesGKent/RPIO/tree/v2 Thanks! |
|
Sorry, it should be OK, because timestamp issue the RPIO not overwrite installed |
|
Hi, I had to revisit this work on a newer kernel after a failed SD card forced me to reinstall.
Thanks! |
|
Cool! I don't have time to work actively on RPIO anymore. Would you be interested in maintaining a fork, and I'll put a prominent link to it on top of the README? Also would be great to test and merge support for Pi3, which I believe works in either the dev branch or other PRs. |
|
@hlc111 sorry for not seeing this and replying sooner, using the PWM on DMA channel 0 i had the same crash, but if you use channel 1 or higher should be ok, please try this and report back? |
|
@metachris I wouldn't mind helping with pull requests and reviews, but I don't think I'd have time to maintain a fork and take care of releases all by myself either... @JamesGKent If I'm not mistaken, your pull request seems to work on most Pi boards, provided a small #include fix is made, is that correct? |
|
@Yackou I've made the include fix in another commit to this pull. |
|
@JamesGKent sounds like the DMA channel 0 issue deserves its own ticket, no? Would hate to have that hold up a pull for this critical ticket... I'd be happy to take a look at that if its filed separately with a sample snippet showing the lockup... just tag me somehow... |
|
Agree the DMA channel 0 issue should go into its own ticket. I was trying to find a way to determine which DMA channels are already used by the kernel, and I found this: @JamesGKent I haven't tested your last commit yet, but the diff is exactly the same as what I did, so I don't expect any issue. BTW, I am using PWM on a Pi2 (it's my main reason for using RPIO), so you can mark it as working (I do use the regular GPIO API as well). |
|
@Yackou that would make sense about DMA 0, when i first noticed the crash i was working on a pi that was running a desktop (PIXEL) for unrelated reasons i ended up wiping and starting with a fresh image booting to command line (wanted more performance headroom and didn't need desktop) and the crash appeared to stop happening... i'll look into adding a get_channel function if i have time. |
|
@JamesGKent Actually, there might be a problem with your pull request, as I now get git errors when trying to check out your branch: in commit f861be9 (fix getting per_base for new pis in pwm extension), it looks like you turned 2 symlinks into files (conf.py, index.rst), or something similar (where you under windows maybe?). Linux git doesn't like that apparently... Not sure why I didn't experience this before though. |
|
@JamesGKent FWIW, I think I have solved the symlink problem in my tree; check the branch JGK-v2. |
|
most of my work has been either under windows or through the web interface, so entirely possible i broke it... as much as i like linux, too many things i use are windows only so i spend far more time on windows. I've now got a little one at home so i get less time to tinker with things like this, but when i get a chance i'll try your branch and report back, although my original use case has vanished due to being unable to get a SPI device working (even though it looked right on a scope...) so driving everything through an arduino instead, including PWM |
|
a02082 basic functionality works for me with your branch - thx |
this incorporates the fixes in Yackou's V2 branch that includes a more robust method of detecting the cpu on the pi to determine feature availability.
This includes updates for all known pi variants at this time.
I intend to test the following items before this pull request gets closed, if anyone can test any additional pi's or features it would be appreciated.
importable on:
pwm functions on: