I’ve setup 3 Zymkeys on Raspberry Pi 4s identically. On the 3rd, after running the scripts the LED pattern went to 8 slow / 10 quick and dmesg shows a bunch of:
[ 40.631223] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 41.671226] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 42.711232] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 43.751233] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 44.791231] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 45.831228] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 46.871226] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 47.911228] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 48.951229] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 49.991225] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 51.191237] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 52.231232] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
I have no undervolt messages, this is the same setup I’ve used with the other two devices for power, and I think it successfully encrypted itself:
[ 0.000000] Kernel command line: coherent_pool=1M 8250.nr_uarts=0 snd_bcm2835.enable_compat_alsa=0 snd_bcm2835.enable_hdmi=1 snd_bcm2835.enable_headphones=1 smsc95xx.macaddr=DC:A6:32:CF:F8:B4 vc_mem.mem_base=0x3ec00000 vc_mem.mem_size=0x40000000 console=ttyS0,115200 console=tty1 elevator=deadline fsck.repair=yes rootwait root=/dev/mapper/cryptrfs cryptdevice=/dev/mmcblk0p2:cryptrfs rng_core.default_quality=1000
Any thoughts on what this could be?
@Kshrwood02, Can you confirm that you enabled the i2c bus on the 3rd Pi? After completing the install_zk_sw.sh script, did the Zymkey binding complete - LED blinks once every 3 seconds?
Bob
Just to be sure, I re-enabled the i2c bus and rebooted. I also powered everything off, disconnected everything, reconnected, and still got the same 8 and 10 pattern.
When the Pi is first powered on it’s a continuous fast blink. After the Pi boots it goes to 8 and 10. I haven’t seen it go once every 3 seconds in between but I can’t say I watched closely enough to see when it changed from continuous blinking.
Because the pattern changes when the Pi boots up I assume it’s communicating with the device though.
That pattern is indicative of an electrical problem communicating with the Zymkey, like a conflict on the i2c bus or with another device like a HAT or something maybe using GPIO4 in particular. Is there anything unique to that PI vs your other two? Can you send me your /boot/config.txt so I can take a look?
Bob
No other HATs, nothing using GPIO. I had a USB device plugged in but no change with that unplugged.
One of the other boxes is now on a different power supply and it does get occasional undervolt messages, but the zymkey is flashing normally on it.
Config.txt from the affected pi:
For more options and information see
Some settings may impact device functionality. See link above for details
uncomment if you get no picture on HDMI for a default “safe” mode
#hdmi_safe=1
uncomment this if your display has a black border of unused pixels visible
and your display can output without overscan
#disable_overscan=1
uncomment the following to adjust overscan. Use positive numbers if console
goes off screen, and negative if there is too much border
#overscan_left=16
#overscan_right=16
#overscan_top=16
#overscan_bottom=16
uncomment to force a console size. By default it will be display’s size minus
overscan.
#framebuffer_width=1280
#framebuffer_height=720
uncomment if hdmi display is not detected and composite is being output
#hdmi_force_hotplug=1
uncomment to force a specific HDMI mode (this will force VGA)
#hdmi_group=1
#hdmi_mode=1
uncomment to force a HDMI mode rather than DVI. This can make audio work in
DMT (computer monitor) modes
#hdmi_drive=2
uncomment to increase signal to HDMI, if you have interference, blanking, or
no display
#config_hdmi_boost=4
uncomment for composite PAL
#sdtv_mode=2
#uncomment to overclock the arm. 700 MHz is the default.
#arm_freq=800
Uncomment some or all of these to enable the optional hardware interfaces
dtparam=i2c_arm=on
#dtparam=i2s=on
#dtparam=spi=on
Uncomment this to enable infrared communication.
#dtoverlay=gpio-ir,gpio_pin=17
#dtoverlay=gpio-ir-tx,gpio_pin=18
Additional overlays and parameters are documented /boot/overlays/README
Enable audio (loads snd_bcm2835)
dtparam=audio=on
[pi4]
Enable DRM VC4 V3D driver on top of the dispmanx display stack
dtoverlay=vc4-fkms-v3d
max_framebuffers=2
[all]
#dtoverlay=vc4-fkms-v3d
initramfs initrd.img followkernel
config.txt looks fine. This might be a bit of a long shot, but we have seen occasional issues due to the CPU scaling governor on the PI4. You could try the workaround outlined here:
https://community.zymbit.com/t/dev-team-known-issues/996/2
I made the permanent change and rebooted, but I’m still getting the 8x10 flash with i2c transfer timed out:
[ 57.271243] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 59.351225] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 60.391203] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
[ 61.431211] i2c-bcm2835 fe804000.i2c: i2c transfer timed out
pi@raspberrypi:~ $ cat /sys/devices/system/cpu/cpufreq/policy0/scaling_governor
performance
It looks like it’s working though, the drive is encrypted and won’t boot without the Zymkey in place.
I should mention the first two I built with a clean USB drive, the 3rd one I re-used the existing drive to clone the 2nd, following this:
One thing to note is that, if the external storage device has an ext4 formatted partition with the original root file system partition (e.g. /dev/mmcblk0p2) on it, this script will use what is already on the external storage device to convert the SD card. This cuts down time for converting lots of Pi root file systems and allows the script to be used in a mass production deployment.
I know you mentioned your power already but I just want to double-check that you have a good power supply. The PI4 requires something on the order of 3.5 Amps. A marginal power source can cause some strange issues that are very hard to track down.
One other thing you could try to narrow down the hardware problem would be to take
the Zymkey from one of the working setups and run through the install/encryption process on the “bad” Pi4 / SD-card combo. Then we could identify whether it’s something with the PI or something with the Zymkey itself.