Linux: EPD Fuse issue on 4.9.y?

[shawaj]

See this issue - https://github.com/PiSupply/PaPiRus/issues/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?

[Dom1n1c]

https://github.com/Hexxeh/rpi-firmware/commit/52241088c1da59a359110d39c1875cda56496764 is the last kernel that works for the PaPiRus on Raspberry Pi Zero and Zero W.

[pelwell]

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.

[shawaj]

@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?

[pelwell]

No - I'm not aware of any SPI/I2C differences on a Pi Zero.

[shawaj]

Ok will perform some more tests and report back

On 17 Mar 2017 1:21 pm, "Phil Elwell" [e-mail] 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
https://github.com/raspberrypi/linux/issues/1902#issuecomment-287351752,
or mute the thread
https://github.com/notifications/unsubscribe-auth/ADNCuj6O46X-OamDX8SAJt2bMAQttqh5ks5rmojAgaJpZM4MfRWz
.

[shawaj]

Ok, testing with 2.7" screen, using PaPiRus HAT on a Pi 3.

uname -a gives Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
Then updated using rpi-update, and a uname -a gives Linux raspberrypi 4.9.14-v7+ #977 SMP Mon Mar 13 18:25:19 GMT 2017 armv7l GNU/Linux

Full update text below:

pi@raspberrypi:~ $ uname -a
Linux raspberrypi 4.4.50-v7+ #970 SMP Mon Feb 20 19:18:29 GMT 2017 armv7l GNU/Linux
pi@raspberrypi:~ $ sudo rpi-update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** Performing self-update
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100 12762  100 12762    0     0   130k      0 --:--:-- --:--:-- --:--:--  132k
 *** Relaunching after update
 *** Raspberry Pi firmware updater by Hexxeh, enhanced by AndrewS and Dom
 *** We're running for the first time
 *** Backing up files (this will take a few minutes)
 *** Backing up firmware
 *** Backing up modules 4.4.50-v7+
#############################################################
WARNING: This update bumps to rpi-4.9.y linux tree
Be aware there could be compatibility issues with some drivers
Discussion here:
https://www.raspberrypi.org/forums/viewtopic.php?f=29&t=167934
##############################################################
Would you like to proceed? (y/N)
 *** Downloading specific firmware revision (this will take a few minutes)
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   168    0   168    0     0    348      0 --:--:-- --:--:-- --:--:--   348
100 53.6M  100 53.6M    0     0  3221k      0  0:00:17  0:00:17 --:--:-- 3282k
 *** Updating firmware
 *** Updating kernel modules
 *** depmod 4.9.14-v7+
 *** depmod 4.9.14+
 *** Updating VideoCore libraries
 *** Using HardFP libraries
 *** Updating SDK
 *** Running ldconfig
 *** Storing current firmware revision
 *** Deleting downloaded files
 *** Syncing changes to disk
 *** If no errors appeared, your firmware was successfully updated to b30461d2621e71eb9b8845b38738af177b9181ed
 *** A reboot is needed to activate the new firmware

This results in the same error seen by @Dom1n1c on the Pi Zero:

pi@raspberrypi:~ $ sudo papirus-write "test"
Writing to Papirus.......
Traceback (most recent call last):
  File "/usr/local/bin/papirus-write", line 34, in <module>
    main()
  File "/usr/local/bin/papirus-write", line 30, in main
    text.AddText(args.content, args.posX, args.posY, args.fsize)
  File "/usr/local/lib/python2.7/dist-packages/papirus/textpos.py", line 43, in AddText
    self.WriteAll()
  File "/usr/local/lib/python2.7/dist-packages/papirus/textpos.py", line 142, in WriteAll
    self.papirus.partial_update()
  File "/usr/local/lib/python2.7/dist-packages/papirus/epd.py", line 149, in partial_update
    self._command('P')
  File "/usr/local/lib/python2.7/dist-packages/papirus/epd.py", line 156, in _command
    f.write(c)
IOError: [Errno 103] Software caused connection abort

As mentioned by @Dom1n1c running rpi-update 52241088c1da59a359110d39c1875cda56496764 fixes the problem.

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?

[shawaj]

Also getting following error messages:

pi@raspberrypi:~ $ sudo papirus-clock
Traceback (most recent call last):
  File "/usr/local/bin/papirus-clock", line 123, in <module>
    main(sys.argv[1:])
  File "/usr/local/bin/papirus-clock", line 66, in main
    papirus = Papirus()
  File "/usr/local/lib/python2.7/dist-packages/papirus/epd.py", line 66, in __init__
    with open(os.path.join(self._epd_path, 'version')) as f:
IOError: [Errno 107] Transport endpoint is not connected: '/dev/epd/version'
pi@raspberrypi:~ $ sudo papirus-gol
Traceback (most recent call last):
  File "/usr/local/bin/papirus-gol", line 118, in <module>
    main()
  File "/usr/local/bin/papirus-gol", line 91, in main
    epd = Papirus()
  File "/usr/local/lib/python2.7/dist-packages/papirus/epd.py", line 66, in __init__
    with open(os.path.join(self._epd_path, 'version')) as f:
IOError: [Errno 107] Transport endpoint is not connected: '/dev/epd/version'

[tvoverbeek]

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.
We should really get worried if it is an issue in the mainstream kernel provided by the RPi Foundation via download and subsequent apt-get update (now stil on 4.4.x).
@shawaj nor reallogic analyzer here, but a Bitscope mini is available (www.bitscope.com/pi)

[tvoverbeek]

The error you get is also an indication the epd-fuse did not load correctly since /dev/epd/version cannot be read.

[shawaj]

@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 :-)

[Dom1n1c]

@tvoverbeek of course you could say, that we should avoid kernel updates unless they are necessary.
From another project i participate in, the soulution right now is, to deactivate rpi-update.
https://github.com/openhab/openhabian/blob/master/openhabian-setup.sh

[pelwell]

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.

[tvoverbeek]

@pelwell Sorry, this is a red herring. RPI3 (and RPI2) report BCM2709 as CPU (4 cores).
The original single core reports BCM2708 as CPU
BCM2835 refers to the complete chip (e.g. including video core)

[pelwell]

@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:

pi@raspberrypi:~ $ od -Ax -tx1 /proc/device-tree/soc/ranges 
000000 7e 00 00 00 3f 00 00 00 01 00 00 00 40 00 00 00
000010 40 00 00 00 00 04 00 00

3f 00 00 00 = 0x3f000000. On a BCM2708-based device this would say 20 00 00 00 = 0x20000000.

[shawaj]

@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!

[tvoverbeek]

@pelwell I'll shut up for now and do some testing and investigating first with 4.9.x

[shawaj]

@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 {"BCM2835", V2_BCM_PERIPHERALS_ADDRESS} here - https://github.com/repaper/gratis/blob/master/PlatformWithOS/RaspberryPi/gpio.c#L222

be a sufficient fix in the short term perhaps?

[pelwell]

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.

[pelwell]

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.

[pelwell]

Try this

bool get_cpu_io_base_address(uint32_t *base) {

    char buffer[8];
    const char *ranges_file = "/proc/device-tree/soc/ranges";
    int info_fd = open(ranges_file, O_RDONLY);

    if (info_fd < 0) {
        warn("cannot open: %s", ranges_file);
        return false;
    }

    ssize_t n = read(info_fd, buffer, sizeof(buffer) );
    close(info_fd);

    if (n != 8) {
        warn("cannot read base address: %s", ranges_file);
        return false;
    }

    *base =  (buffer[4] << 24) + (buffer[5] << 16) + (buffer[6] << 8) + (buffer[7] << 0);

    return true;
}

[pelwell]

I've tweaked it a bit - it ought to compile now and include error checking.

[shawaj]

wow, thanks @pelwell - that is awesome :-)

Testing now

[tvoverbeek]

@pelwell @shawaj Just tested @pelwell's get_cpu_io_base_address with a 4.9.x kernel and everything works.
Thanks Phil.
Will continue looking for a more elegant solution, e.g. using /dev/gpiomem.

[shawaj]

@tvoverbeek - I am getting the following error:

pi@raspberrypi:~/gratis $ sudo make rpi EPD_IO=epd_io.h PANEL_VERSION='V231_G2'
make DESTDIR="" PREFIX=/usr SERVICE=systemd PLATFORM=../RaspberryPi PANEL_VERSION="V231_G2" EPD_IO="epd_io.h" -C PlatformWithOS/driver-common
make[1]: Entering directory '/home/pi/gratis/PlatformWithOS/driver-common'
cc -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse  -Wall -Werror -std=gnu99 -I../RaspberryPi -IV231_G2 -I. -DEPD_IO='"epd_io.h"'   -c -o gpio_test.o gpio_test.c
cc -D_FILE_OFFSET_BITS=64 -I/usr/include/fuse  -Wall -Werror -std=gnu99 -I../RaspberryPi -IV231_G2 -I. -DEPD_IO='"epd_io.h"'   -c -o gpio.o ../RaspberryPi/gpio.c
../RaspberryPi/gpio.c: In function ‘get_cpu_io_base_address’:
../RaspberryPi/gpio.c:410:10: error: unused variable ‘n’ [-Werror=unused-variable]
  ssize_t n = read(info_fd, buffer, sizeof(buffer) );
          ^
cc1: all warnings being treated as errors
<builtin>: recipe for target 'gpio.o' failed
make[1]: *** [gpio.o] Error 1
make[1]: Leaving directory '/home/pi/gratis/PlatformWithOS/driver-common'
Makefile:84: recipe for target 'rpi' failed
make: *** [rpi] Error 2

Did you get this also?

[pelwell]

It looks like you grabbed an unfinished version of the code - this is what it looks like now:

bool get_cpu_io_base_address(uint32_t *base) {

    char buffer[8];
    const char *ranges_file = "/proc/device-tree/soc/ranges";
    int info_fd = open(ranges_file, O_RDONLY);

    if (info_fd < 0) {
        warn("cannot open: %s", ranges_file);
        return false;
    }

    ssize_t n = read(info_fd, buffer, sizeof(buffer) );
    close(info_fd);

    if (n != 8) {
        warn("cannot read base address: %s", ranges_file);
        return false;
    }

    *base =  (buffer[4] << 24) + (buffer[5] << 16) + (buffer[6] << 8) + (buffer[7] << 0);

    return true;
}

[shawaj]

@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 :-)

[shawaj]

Fixed here - https://github.com/repaper/gratis/pull/64