EPD Fuse issue on 4.9.y? #1902

shawaj · 2017-03-16T13:05:51Z

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?

3DJupp · 2017-03-16T23:00:18Z

Hexxeh/rpi-firmware@5224108 is the last kernel that works for the PaPiRus on Raspberry Pi Zero and Zero W.

pelwell · 2017-03-17T08:58:47Z

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 · 2017-03-17T13:18:33Z

@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 · 2017-03-17T13:20:54Z

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

shawaj · 2017-03-17T13:23:38Z

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> .

shawaj · 2017-03-17T13:51:04Z

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 · 2017-03-17T13:57:45Z

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 · 2017-03-17T13:58:37Z

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 · 2017-03-17T14:00:34Z

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

shawaj · 2017-03-17T14:02:32Z

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

3DJupp · 2017-03-17T14:03:41Z

@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 · 2017-03-17T14:05:14Z

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 · 2017-03-17T14:11:41Z

@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 · 2017-03-17T14:17:01Z

@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 · 2017-03-17T14:19:01Z

@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 · 2017-03-17T14:27:16Z

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

shawaj · 2017-03-17T14:31:33Z

@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 · 2017-03-17T14:33:34Z

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 · 2017-03-17T14:34:51Z

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 · 2017-03-17T14:38:11Z

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 · 2017-03-17T14:41:40Z

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

shawaj · 2017-03-17T14:42:35Z

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

Testing now

tvoverbeek · 2017-03-17T15:38:27Z

@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 · 2017-03-17T15:50:57Z

@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 · 2017-03-17T16:00:20Z

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 · 2017-03-17T16:20:15Z

@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 · 2017-03-17T16:28:54Z

Fixed here - repaper/gratis#64

shawaj mentioned this issue Mar 17, 2017

Latest Kernel (4.9.x) on Raspberry Pi Zero / Pi Zero W PiSupply/PaPiRus#82

Closed

shawaj mentioned this issue Mar 17, 2017

Problem with latest Raspberry Pi Kernel rpi-4.9.y repaper/gratis#62

Closed

shawaj mentioned this issue Mar 17, 2017

Refactor to use sysfs interface or dedicated kernel driver repaper/gratis#63

Open

shawaj closed this as completed Mar 17, 2017

shawaj mentioned this issue Mar 17, 2017

Refactor gratis to use sysfs interface or dedicated kernel driver PiSupply/PaPiRus#89

Open

neuralassembly mentioned this issue Mar 28, 2017

Fixing your patch for kernel 4.9 doublebind/raspi#7

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

EPD Fuse issue on 4.9.y? #1902

EPD Fuse issue on 4.9.y? #1902

shawaj commented Mar 16, 2017

3DJupp commented Mar 16, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017 via email

shawaj commented Mar 17, 2017

shawaj commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

3DJupp commented Mar 17, 2017

pelwell commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017 •

edited

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

pelwell commented Mar 17, 2017

pelwell commented Mar 17, 2017 •

edited

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

shawaj commented Mar 17, 2017

EPD Fuse issue on 4.9.y? #1902

EPD Fuse issue on 4.9.y? #1902

Comments

shawaj commented Mar 16, 2017

3DJupp commented Mar 16, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017 via email

shawaj commented Mar 17, 2017

shawaj commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

3DJupp commented Mar 17, 2017

pelwell commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017 • edited

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

pelwell commented Mar 17, 2017

pelwell commented Mar 17, 2017 • edited

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

tvoverbeek commented Mar 17, 2017

shawaj commented Mar 17, 2017

pelwell commented Mar 17, 2017

shawaj commented Mar 17, 2017

shawaj commented Mar 17, 2017

shawaj commented Mar 17, 2017 •

edited

pelwell commented Mar 17, 2017 •

edited