-
Notifications
You must be signed in to change notification settings - Fork 4.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
EPD Fuse issue on 4.9.y? #1902
Comments
Hexxeh/rpi-firmware@5224108 is the last kernel that works for the PaPiRus on Raspberry Pi Zero and Zero W. |
We don't have the bandwidth to support third-party products - it's up to the vendor to identify problems in the kernel, drivers or firmware, at which point we can do something about it. I suggest you put a logic analyzer on the SPI and I2C signals - Saleae make some inexpensive units that decode protocols SPI and I2C - and look for differences between the two kernels. |
@dom1n1c - can you confirm whether this issue is Pi Zero specific or whether it happens on every Pi with latest firmware? @pelwell - are you aware of any differences between Pi zero and the other boards in terms of SPI / I2C implementation that could cause something like this to be on those boards but not others? |
No - I'm not aware of any SPI/I2C differences on a Pi Zero. |
Ok will perform some more tests and report back
…On 17 Mar 2017 1:21 pm, "Phil Elwell" ***@***.***> wrote:
No - I'm not aware of any SPI/I2C differences on a Pi Zero.
—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
<#1902 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/ADNCuj6O46X-OamDX8SAJt2bMAQttqh5ks5rmojAgaJpZM4MfRWz>
.
|
Ok, testing with 2.7" screen, using PaPiRus HAT on a Pi 3.
Full update text below:
This results in the same error seen by @dom1n1c on the Pi Zero:
As mentioned by @dom1n1c running So looks like it is not specific to Pi Zero and/or PaPiRus Zero but actually is just an issue with EPD FUSE and the new firmware. @pelwell any hints / tips on what you think I should be looking out for when trying to debug SPI / I2C using a logic analyser? @francesco-vannini @tvoverbeek - have either of you got a logic analyser anywhere knocking around or should I pick up one from Salae? |
Also getting following error messages:
|
rpi-update always gives you the bleeding edge (non official yet) version of the kernel. Would suggest you report the issue on github.com/raspberrypi/linux. Probably an incompatibility between 4.9.x kernel and the version of libfuse we are using. |
The error you get is also an indication the epd-fuse did not load correctly since /dev/epd/version cannot be read. |
@tvoverbeek - so maybe a libfuse update would fix this? Guessing that comes from the https://github.com/repaper/gratis/ code? Sounds like 4.9.y is not far off from being the mainstream kernel, so keen to debug at this stage rather then when it is live :-) |
@tvoverbeek of course you could say, that we should avoid kernel updates unless they are necessary. |
I think I've found something: https://github.com/repaper/gratis/blob/master/PlatformWithOS/RaspberryPi/gpio.c#L220 They're using a hacky baremetal GPIO driver that will be failing to determine the platform because /proc/cpuinfo will now report BCM2835 rather than BCM2708 or BCM2709. |
@pelwell Sorry, this is a red herring. RPI3 (and RPI2) report BCM2709 as CPU (4 cores). |
@tvoverbeek You don't know what you are talking about. Read the code: https://github.com/repaper/gratis/blob/master/PlatformWithOS/RaspberryPi/gpio.c#L399 From rpi-4.9.y onwards, all bcm2835-derived chips will report their board identifier as BCM2835. In an ideal world they would be using the kernel GPIO driver via the sysfs interface or a dedicated kernel driver, but in the short term they should be reading the I/O base address from /proc/device-tree/soc/ranges - bytes 4-7:
|
@pelwell - addressing the hackiness of the driver - is there a way you would suggest us refactoring this GPIO driver in the future? EDIT: only just seen your latest reply - sorry! |
@pelwell I'll shut up for now and do some testing and investigating first with 4.9.x |
@pelwell - these base addresses already seem to be here - https://github.com/repaper/gratis/blob/master/PlatformWithOS/RaspberryPi/gpio.c#L39 Would adding an option of be a sufficient fix in the short term perhaps? |
No, because both of the old labels (BCM2708->0x20000000 and BCM2709->0x3f000000) have now become BCM2835, so there is no way to tell from that which base address to use. |
Really - just change the logic. That ranges parameter has been there since the first proper Pi DT-enabled kernel which dates back to the Pi2 launch. |
Try this
|
I've tweaked it a bit - it ought to compile now and include error checking. |
wow, thanks @pelwell - that is awesome :-) Testing now |
@tvoverbeek - I am getting the following error:
Did you get this also? |
It looks like you grabbed an unfinished version of the code - this is what it looks like now:
|
@pelwell - doh! I am a muppet. GItHub seemed to add replies beneath, but not update the previous ones. Should have F5d Anyway - all working here now too. Closing this now. Thanks again 👍 And thanks @tvoverbeek also :-) |
Fixed here - repaper/gratis#64 |
See this issue - PiSupply/PaPiRus#82
We have a customer reporting incompatibility of 4.9.y kernel with our EPD FUSE implementation for PaPiRus.
Happy to do the fixes our side but at the moment struggling to see what could be causing the issue. Can you help at all?
The text was updated successfully, but these errors were encountered: