Could not detect Raspberry Pi 3B+ on linux 4.19 64-bit

[jkeller1ca]

I built my version of pigpio under buildroot and used the raspberry pi 3B default configs. Unfortunately, pigpiod just hung on startup (as well as any client like node-red or pigs).

This is against v73 and linux 4.19-75 64-bit. I tracked it down to a failure in gpioHardwareRevision(). While the board is detected as a raspberry pi, the /proc/cpuinfo file seems to have changed format.

I'm ready with a patch to get it working, we just needed to add a new case in the switch statement that checks for revision. Works like a charm!

diff --git a/pigpio.c b/pigpio.c
index 24fe287..e267686 100644
--- a/pigpio.c
+++ b/pigpio.c
@@ -13513,6 +13513,20 @@ unsigned gpioHardwareRevision(void)
                else rev &= 0xFFFFFF; /* mask out warranty bit */
                switch (rev&0xFFF0)  /* just interested in BCM model */
                {
+                  case 0x20D0: /* Pi3B */
+                     pi_ispi = 1;
+                     piCores = 4;
+                     pi_peri_phys = 0x3F000000;
+                     pi_dram_bus  = 0xC0000000;
+                     pi_mem_flag  = 0x04;
+                     fclose(filp);
+                     if (!gpioMaskSet)
+                     {
+                        gpioMaskSet = 1;
+                        gpioMask = PI_DEFAULT_UPDATE_MASK_PI3B;
+                     }
+                     return rev;
+                     break;
                   case 0x3110: /* Pi4B */
                      piCores = 4;
                      pi_peri_phys = 0xFE000000;
-- 
2.17.1

[guymcswain]

Please describe in more detail how you initiate pigpiod and the 'hang condition' associated with pigs.

[jkeller1ca]

Please describe in more detail how you initiate pigpiod and the 'hang condition' associated with pigs.

I built and ran pigpiod as compiled from sources within buildroot using gcc 9. Their package definition is here: https://github.com/buildroot/buildroot/tree/master/package/pigpio I'm running on a Raspberry Pi 3B+

I launched it as a process with the following command line:
/usr/bin/pigpiod -l -n 127.0.0.1

When I tried to query the state of one of the output pins using 'pigs r 17', the pigs program just hung. No response, used CTRL-C to exit. Using strace, I could see that the socket got connected, but the other side didn't accept it.

I then used gdb and strace to debug the pigpiod service and saw it was in a quick query loop somewhere in the initialization phase. I then stepped through the gpioHardwareRevision() function and saw the routine wasn't detecting my Raspberry Pi 3B correctly.

Looks like my kernel generates a different version of /proc/cpuinfo than what pigpiod was expecting. Specifically there's no mention of "model name" in my cpuinfo:

# cat /proc/cpuinfo 
processor	: 0
BogoMIPS	: 38.40
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 1
BogoMIPS	: 38.40
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 2
BogoMIPS	: 38.40
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

processor	: 3
BogoMIPS	: 38.40
Features	: fp asimd evtstrm crc32 cpuid
CPU implementer	: 0x41
CPU architecture: 8
CPU variant	: 0x0
CPU part	: 0xd03
CPU revision	: 4

Hardware	: BCM2835
Revision	: a020d3
Serial		: 000000001cc6ed17
Model		: Raspberry Pi 3 Model B Plus Rev 1.3

So, while the code detected it was a rasp pi (by setting pi_ispi ==true at line 13504), we never got to look at the device tree because pi_ispi was true on line 13550.

I think what was happening was that the receive socket was created , but since we were stuck waiting for hardware to initialize because the memory map wasn't configured, the daemon never called accept() and the client program hung.

[guymcswain]

There very well may be an issue with your /proc/cpuinfo but the socket connection could be a separate issue. I'm pretty sure '-l' has priority over '-n' but will only accept '::1'

Please try without '-l'. And just run pigs hwver.

The question is why? Is this unique to buildroot?

[jkeller1ca]

The question is why? Is this unique to buildroot?

This also might be due to me running a 64-bit kernel. Just guessing here, but it'll take me a bit to rebuild the kernel under 32-bit.

I am also running on the Pi 3B+. I didn't realize the distinction until I started poking around a bit.

[jkeller1ca]

And just run pigs hwver.

For reference, when using my patch:

# pigs hwver
10494163

[guymcswain]

For reference, on my Pi 3B+:

$ uname -a
Linux pigpio-buster-v71 4.19.75-v7+ #1270 SMP Tue Sep 24 18:45:11 BST 2019 armv7l GNU/Linux

$ tail -14 /proc/cpuinfo
processor       : 3
model name      : ARMv7 Processor rev 4 (v7l)
BogoMIPS        : 38.40
Features        : half thumb fastmult vfp edsp neon vfpv3 tls vfpv4 idiva idivt vfpd32 lpae evtstrm crc32
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xd03
CPU revision    : 4

Hardware        : BCM2835
Revision        : a020d3
Serial          : 00000000d4403430
Model           : Raspberry Pi 3 Model B Plus Rev 1.3

It seems that the string 'CPU architecture' identifies the kernel architecture in lieu of 'mode name' from the output of /proc/cpuinfo.

[guymcswain]

@jkeller1ca , I'll be marking this as a duplicate of #266 but if not for your detailed analysis I would not have understood the issue. I think I do now and will be working on a patch soon.

[jkeller1ca]

@jkeller1ca , I'll be marking this as a duplicate of #266 but if not for your detailed analysis I would not have understood the issue. I think I do now and will be working on a patch soon.

My pleasure! Clicky relays all over the world thank you.

[guymcswain]

@jkeller1ca , May I request that you download the proposed patch for this issue and test it on your system?
Please run the following on your raspberry pi:

wget https://github.com/joan2937/pigpio/archive/v7301.zip
unzip v7301.zip
cd pigpio-7301
make
sudo make install

Test your system as normal. If for some reason it fails, capture the initialization log by doing the following:

1. Stop the currently running instance of pigpio.
2. From a working directory, run:
   sudo pigpiod -c4 -g 2> pigpiod.log
   Allow a few seconds to complete initialization, then Cntrl-C (SIGINT) to abort.
   Run
   head pigpiod.log
   If there was any error in the hardware revision decode it should appear in this output.

Thank you very much!

[jkeller1ca]

Easy enough!

I downloaded v7301.zip and temporarily added it to my buildroot setup so that it would be built the same as the original program. Using the same '-n -l 127.0.0.1' command line, both node-red and pigs were able to connect to the server just fine!

That patch seems to work for me! Thanks, @guymcswain

[guymcswain]

I appreciate the quick feedback! I'm going to wait until I get more testing feedback, both from arm64 and 32bit users. It may be until early February before I finally merge into master. Until then you've got the very latest with v7301.