TESTING: ClusterCTRL images (based on Raspberry Pi OS (64 bit) beta)

396 views
Skip to first unread message

Chris Burton

unread,
May 31, 2020, 9:22:11 AM5/31/20
to ClusterHAT
Hi,

I've uploaded a 64 bit controller image for those who want to give it a test to https://dist.8086.net/clusterctrl/testing/

The CNAT/CBRIDGE images should work on Pi3/4 controllers (no usbboot or pX images as the kernel functionfs is missing from the kernel).

This was created using the same script as the regular ClusterCTRL images with the following changes.

1) The *.elf and *.dat files from the master branch of Raspberry Pi Firmware repo have been added to allow direct booting from USB storage on a Pi4 using *BETA* firmware - see official docs for info and how to get the BETA firmware on your Pi4.

2) For rpiboot (Booting Pi Zeros/etc as USB Devices) /var/lib/clusterctrl/boot/bootcode.bin is no longer a link to the controllers /boot/bootcode.bin. It's the last working version pulled from github (see this issue for why) .

For details on the "Raspberry Pi OS (64bit) beta" release see the Raspberry Pi forum post.

Chris.

Gábor Babusa

unread,
Jun 2, 2020, 4:45:55 AM6/2/20
to ClusterHAT
Hi Chris,

Does it means, that if I use the 64bit image I can't use the Zeros without dedicated SD cards anymore?

Chris Burton

unread,
Jun 4, 2020, 3:28:32 PM6/4/20
to ClusterHAT
Hi, 
Does it means, that if I use the 64bit image I can't use the Zeros without dedicated SD cards anymore?

No.

Chris. 

Patrick Nooijen

unread,
Jun 8, 2020, 6:54:35 AM6/8/20
to ClusterHAT
i am using the 64bit image on my pi4 with clusterhat 2.4.
Loaded are 4 pi zero w modules.

all of them load up to 
Jun  8 12:51:57 cbridge rpiboot[601]: Waiting for BCM2835/6/7/2711...

output lsub -t
pi@cbridge:~ $ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 5000M
    |__ Port 1: Dev 2, If 0, Class=Mass Storage, Driver=usb-storage, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 2: Dev 3, If 1, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 2: Dev 3, If 2, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 2: Dev 3, If 0, Class=Human Interface Device, Driver=usbhid, 12M
        |__ Port 3: Dev 5, If 0, Class=Hub, Driver=hub/4p, 480M
        |__ Port 4: Dev 4, If 0, Class=Human Interface Device, Driver=usbhid, 1.5M
        |__ Port 4: Dev 4, If 1, Class=Human Interface Device, Driver=usbhid, 1.5M


Op zondag 31 mei 2020 15:22:11 UTC+2 schreef Chris Burton:

Patrick Nooijen

unread,
Jun 8, 2020, 6:55:04 AM6/8/20
to ClusterHAT
pi@cbridge:~ $ uname -r
5.4.42-v8+


Op maandag 8 juni 2020 12:54:35 UTC+2 schreef Patrick Nooijen:

Patrick Nooijen

unread,
Jun 8, 2020, 6:56:08 AM6/8/20
to ClusterHAT
pi@cbridge:~ $ clusterctrl status
clusterhat:1
clusterctrl:False
maxpi:4
hat_version:2.4
hat_version_major:2
hat_version_minor:4
hat_size:4
hat_uuid:de91a4ce-ac7f-11e9-a2a3-2a2ae2dbcce4
hat_vendor:8086 Consultancy
hat_product_id:0x0004
throttled:0x0
hat_alert:0
hat_hub:1
hat_wp:1
hat_led:1
hat_wplink:0
hat_xra1200p:True
p1:0
p2:1
p3:1
p4:0

Patrick Nooijen

unread,
Jun 8, 2020, 7:09:42 AM6/8/20
to ClusterHAT
pi@cbridge:~ $ clusterctrl on p4
pi@cbridge:~ $ tail -f /var/log/daemon.log /var/log/kern.log
==> /var/log/daemon.log <==
Jun  8 13:07:29 cbridge systemd[1]: var-lib-rancher-k3s-agent-containerd-tmpmounts-containerd\x2dmount797109461.mount: Succeeded.
Jun  8 13:07:29 cbridge systemd[1]: var-lib-rancher-k3s-agent-containerd-tmpmounts-containerd\x2dmount586960944.mount: Succeeded.
Jun  8 13:07:30 cbridge systemd[1]: run-containerd-runc-k8s.io-c1cf774bb78149290866f698a6a1948f70670be76778479c98fe551437f1e9ab-runc.GliJLN.mount: Succeeded.
Jun  8 13:07:30 cbridge dhcpcd[427]: veth9adbb5c9: probing for an IPv4LL address
Jun  8 13:07:35 cbridge dhcpcd[427]: veth9adbb5c9: using IPv4LL address 169.254.59.11
Jun  8 13:07:35 cbridge avahi-daemon[392]: Joining mDNS multicast group on interface veth9adbb5c9.IPv4 with address 169.254.59.11.
Jun  8 13:07:35 cbridge dhcpcd[427]: veth9adbb5c9: adding route to 169.254.0.0/16
Jun  8 13:07:35 cbridge avahi-daemon[392]: New relevant interface veth9adbb5c9.IPv4 for mDNS.
Jun  8 13:07:35 cbridge avahi-daemon[392]: Registering new address record for 169.254.59.11 on veth9adbb5c9.IPv4.
Jun  8 13:07:38 cbridge dhcpcd[427]: veth9adbb5c9: no IPv6 Routers available

==> /var/log/kern.log <==
Jun  8 13:07:10 cbridge kernel: [   42.240306] IPVS: [wrr] scheduler registered.
Jun  8 13:07:10 cbridge kernel: [   42.249657] IPVS: [sh] scheduler registered.
Jun  8 13:07:10 cbridge kernel: [   42.590218] kmem.limit_in_bytes is deprecated and will be removed. Please report your usecase to linu...@kvack.org if you depend on this functionality.
Jun  8 13:07:25 cbridge kernel: [   57.660720] IPv6: ADDRCONF(NETDEV_CHANGE): veth9adbb5c9: link becomes ready
Jun  8 13:07:25 cbridge kernel: [   57.660886] IPv6: ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
Jun  8 13:07:25 cbridge kernel: [   57.661877] cni0: port 1(veth9adbb5c9) entered blocking state
Jun  8 13:07:25 cbridge kernel: [   57.661887] cni0: port 1(veth9adbb5c9) entered disabled state
Jun  8 13:07:25 cbridge kernel: [   57.662242] device veth9adbb5c9 entered promiscuous mode
Jun  8 13:07:25 cbridge kernel: [   57.662535] cni0: port 1(veth9adbb5c9) entered blocking state
Jun  8 13:07:25 cbridge kernel: [   57.662541] cni0: port 1(veth9adbb5c9) entered forwarding state
Jun  8 13:08:48 cbridge kernel: [  140.147470] usb 1-1.3: new high-speed USB device number 5 using xhci_hcd
Jun  8 13:08:48 cbridge kernel: [  140.252679] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=85.36
Jun  8 13:08:48 cbridge kernel: [  140.252694] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Jun  8 13:08:48 cbridge kernel: [  140.252704] usb 1-1.3: Product: USB2.0 Hub
Jun  8 13:08:48 cbridge kernel: [  140.256121] hub 1-1.3:1.0: USB hub found
Jun  8 13:08:48 cbridge kernel: [  140.257570] hub 1-1.3:1.0: 4 ports detected

==> /var/log/daemon.log <==
Jun  8 13:08:48 cbridge rpiboot[601]: libusb: error [udev_hotplug_event] ignoring udev action bind

==> /var/log/kern.log <==
Jun  8 13:08:48 cbridge kernel: [  140.547427] usb 1-1.3.1: new full-speed USB device number 6 using xhci_hcd
Jun  8 13:08:48 cbridge kernel: [  140.653299] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00
Jun  8 13:08:48 cbridge kernel: [  140.653309] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun  8 13:08:48 cbridge kernel: [  140.653314] usb 1-1.3.1: Product: BCM2708 Boot
Jun  8 13:08:48 cbridge kernel: [  140.653318] usb 1-1.3.1: Manufacturer: Broadcom

==> /var/log/daemon.log <==
Jun  8 13:08:48 cbridge rpiboot[601]: Device located successfully
Jun  8 13:08:48 cbridge rpiboot[601]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun  8 13:08:49 cbridge rpiboot[601]: Initialised device correctly
Jun  8 13:08:49 cbridge rpiboot[601]: Found serial number 0
Jun  8 13:08:49 cbridge rpiboot[601]: Sending bootcode.bin
Jun  8 13:08:49 cbridge rpiboot[601]: libusb_bulk_transfer sent 24 bytes; returned 0
Jun  8 13:08:49 cbridge rpiboot[601]: Writing 52480 bytes
Jun  8 13:08:49 cbridge rpiboot[601]: libusb_bulk_transfer sent 52480 bytes; returned 0
Jun  8 13:08:50 cbridge rpiboot[601]: Failed : 0x0

==> /var/log/kern.log <==
Jun  8 13:08:50 cbridge kernel: [  142.773106] usb 1-1.3.1: USB disconnect, device number 6

==> /var/log/daemon.log <==
Jun  8 13:08:51 cbridge rpiboot[601]: Waiting for BCM2835/6/7/2711...

Chris Burton

unread,
Jun 8, 2020, 8:00:25 PM6/8/20
to ClusterHAT
Hi, 
Jun  8 13:08:49 cbridge rpiboot[601]: Writing 52480 bytes

Looking at the size of the bootcode.bin above I think it's the wrong version (Looks like I missed updating it), can you run this on it and let me know if you can use rpiboot again.

sudo rm /var/lib/clusterctrl/boot/bootcode.bin
sudo wget
-O /var/lib/clusterctrl/boot/bootcode.bin https://github.com/Hexxeh/rpi-firmware/raw/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin
sudo service clusterctrl
-rpiboot restart

Chris.

Patrick Nooijen

unread,
Jun 9, 2020, 6:37:33 AM6/9/20
to ClusterHAT
still stuck at waiting for bcm.
Tried it on the 32bit and your solution worked on that version.

Op dinsdag 9 juni 2020 02:00:25 UTC+2 schreef Chris Burton:

Patrick Nooijen

unread,
Jun 9, 2020, 6:44:21 AM6/9/20
to ClusterHAT
pi@cbridge:~ $ tail -f /var/log/daemon.log /var/log/kern.log
==> /var/log/daemon.log <==
Jun  9 12:39:44 cbridge dhcpcd[453]: br0: leased 192.168.178.46 for 86400 seconds
Jun  9 12:39:44 cbridge avahi-daemon[377]: Joining mDNS multicast group on interface br0.IPv4 with address 192.168.178.46.
Jun  9 12:39:44 cbridge avahi-daemon[377]: New relevant interface br0.IPv4 for mDNS.
Jun  9 12:39:44 cbridge avahi-daemon[377]: Registering new address record for 192.168.178.46 on br0.IPv4.
Jun  9 12:39:44 cbridge dhcpcd[453]: br0: adding route to 192.168.178.0/24
Jun  9 12:39:44 cbridge dhcpcd[453]: br0: adding default route via 192.168.178.1
Jun  9 12:39:47 cbridge systemd[1]: systemd-fsckd.service: Succeeded.
Jun  9 12:39:47 cbridge dhcpcd[453]: br0: no IPv6 Routers available
Jun  9 12:40:13 cbridge systemd[1]: systemd-hostnamed.service: Succeeded.
Jun  9 12:43:01 cbridge systemd[1]: Started Session c3 of user pi.

==> /var/log/kern.log <==
Jun  9 12:39:29 cbridge kernel: [   19.249341] bcmgenet fd580000.ethernet: configuring instance for external RGMII
Jun  9 12:39:29 cbridge kernel: [   19.249656] bcmgenet fd580000.ethernet eth0: Link is Down
Jun  9 12:39:31 cbridge kernel: [   21.020770] NFSD: Using UMH upcall client tracking operations.
Jun  9 12:39:31 cbridge kernel: [   21.020788] NFSD: starting 90-second grace period (net f0000041)
Jun  9 12:39:32 cbridge kernel: [   22.801478] broken atomic modeset userspace detected, disabling atomic
Jun  9 12:39:34 cbridge kernel: [   24.351160] bcmgenet fd580000.ethernet eth0: Link is Up - 1Gbps/Full - flow control off
Jun  9 12:39:34 cbridge kernel: [   24.351203] br0: port 1(eth0) entered blocking state
Jun  9 12:39:34 cbridge kernel: [   24.351209] br0: port 1(eth0) entered forwarding state
Jun  9 12:39:34 cbridge kernel: [   24.351322] IPv6: ADDRCONF(NETDEV_CHANGE): br0: link becomes ready
Jun  9 12:39:35 cbridge kernel: [   25.256221] fuse: init (API version 7.31)
Jun  9 12:43:12 cbridge kernel: [  224.695148] usb 1-1.3: new high-speed USB device number 8 using xhci_hcd
Jun  9 12:43:12 cbridge kernel: [  224.796426] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=85.36
Jun  9 12:43:12 cbridge kernel: [  224.796444] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Jun  9 12:43:12 cbridge kernel: [  224.796456] usb 1-1.3: Product: USB2.0 Hub
Jun  9 12:43:12 cbridge kernel: [  224.798141] hub 1-1.3:1.0: USB hub found
Jun  9 12:43:12 cbridge kernel: [  224.798452] hub 1-1.3:1.0: 4 ports detected

==> /var/log/daemon.log <==
Jun  9 12:43:12 cbridge rpiboot[583]: libusb: error [udev_hotplug_event] ignoring udev action bind

==> /var/log/kern.log <==
Jun  9 12:43:12 cbridge kernel: [  225.087112] usb 1-1.3.3: new full-speed USB device number 9 using xhci_hcd
Jun  9 12:43:12 cbridge kernel: [  225.193116] usb 1-1.3.3: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00
Jun  9 12:43:12 cbridge kernel: [  225.193134] usb 1-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun  9 12:43:12 cbridge kernel: [  225.193147] usb 1-1.3.3: Product: BCM2708 Boot
Jun  9 12:43:12 cbridge kernel: [  225.193158] usb 1-1.3.3: Manufacturer: Broadcom

==> /var/log/daemon.log <==
Jun  9 12:43:12 cbridge rpiboot[583]: Device located successfully
Jun  9 12:43:12 cbridge rpiboot[583]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun  9 12:43:13 cbridge rpiboot[583]: Initialised device correctly
Jun  9 12:43:13 cbridge rpiboot[583]: Found serial number 0
Jun  9 12:43:13 cbridge rpiboot[583]: Sending bootcode.bin
Jun  9 12:43:13 cbridge rpiboot[583]: libusb_bulk_transfer sent 24 bytes; returned 0
Jun  9 12:43:13 cbridge rpiboot[583]: Writing 52304 bytes
Jun  9 12:43:13 cbridge rpiboot[583]: libusb_bulk_transfer sent 52304 bytes; returned 0
Jun  9 12:43:14 cbridge rpiboot[583]: Failed : 0x0

==> /var/log/kern.log <==
Jun  9 12:43:14 cbridge kernel: [  227.313333] usb 1-1.3.3: USB disconnect, device number 9

==> /var/log/daemon.log <==
Jun  9 12:43:15 cbridge rpiboot[583]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun  9 12:43:16 cbridge kernel: [  228.774719] usb 1-1.3.3: new full-speed USB device number 10 using xhci_hcd
Jun  9 12:43:16 cbridge kernel: [  228.876655] usb 1-1.3.3: not running at top speed; connect to a high speed hub
Jun  9 12:43:16 cbridge kernel: [  228.882700] usb 1-1.3.3: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun  9 12:43:16 cbridge kernel: [  228.882716] usb 1-1.3.3: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun  9 12:43:16 cbridge kernel: [  228.882729] usb 1-1.3.3: Product: BCM2710 Boot
Jun  9 12:43:16 cbridge kernel: [  228.882740] usb 1-1.3.3: Manufacturer: Broadcom
Jun  9 12:43:16 cbridge kernel: [  228.882751] usb 1-1.3.3: SerialNumber: Broadcom

==> /var/log/daemon.log <==
Jun  9 12:43:16 cbridge rpiboot[583]: Device located successfully
Jun  9 12:43:16 cbridge rpiboot[583]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun  9 12:43:17 cbridge rpiboot[583]: Initialised device correctly
Jun  9 12:43:17 cbridge rpiboot[583]: Found serial number 1
Jun  9 12:43:17 cbridge rpiboot[583]: Second stage boot server
Jun  9 12:43:17 cbridge rpiboot[583]: Received message GetFileSize: autoboot.txt
Jun  9 12:43:17 cbridge rpiboot[583]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun  9 12:43:17 cbridge rpiboot[583]: Cannot open file autoboot.txt
Jun  9 12:43:17 cbridge rpiboot[583]: Received message GetFileSize: config.txt
Jun  9 12:43:17 cbridge rpiboot[583]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun  9 12:43:17 cbridge rpiboot[583]: Cannot open file config.txt
Jun  9 12:43:17 cbridge rpiboot[583]: Received message GetFileSize: recovery.elf
Jun  9 12:43:17 cbridge rpiboot[583]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun  9 12:43:17 cbridge rpiboot[583]: Cannot open file recovery.elf
Jun  9 12:43:17 cbridge rpiboot[583]: Received message GetFileSize: start.elf
Jun  9 12:43:17 cbridge rpiboot[583]: File size = 438936 bytes
Jun  9 12:43:17 cbridge rpiboot[583]: Received message ReadFile: start.elf
Jun  9 12:43:17 cbridge rpiboot[583]: File read: start.elf
Jun  9 12:43:17 cbridge rpiboot[583]: libusb_bulk_transfer sent 438936 bytes; returned 0
Jun  9 12:43:17 cbridge rpiboot[583]: Received message GetFileSize: fixup.dat
Jun  9 12:43:17 cbridge rpiboot[583]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun  9 12:43:17 cbridge rpiboot[583]: Cannot open file fixup.dat
Jun  9 12:43:17 cbridge rpiboot[583]: Second stage boot server done

==> /var/log/kern.log <==
Jun  9 12:43:17 cbridge kernel: [  230.488825] usb 1-1.3.3: USB disconnect, device number 10

==> /var/log/daemon.log <==
Jun  9 12:43:18 cbridge rpiboot[583]: Waiting for BCM2835/6/7/2711...

Patrick Nooijen

unread,
Jun 9, 2020, 7:07:53 AM6/9/20
to ClusterHAT
also this does not work : 

sudo cp -r /usr/share/rpiboot/msd/ /var/lib/clusterctrl/nfs/pX/boot/

directory rpiboot does not exist.

Op dinsdag 9 juni 2020 12:44:21 UTC+2 schreef Patrick Nooijen:

Patrick Nooijen

unread,
Jun 9, 2020, 7:25:28 AM6/9/20
to ClusterHAT
i tried the steps from your manual again after updating bootcode.bin and the CM3 module boots.

Zero keeps geving waiting for bcm..

Op dinsdag 9 juni 2020 13:07:53 UTC+2 schreef Patrick Nooijen:

Chris Burton

unread,
Jun 9, 2020, 6:05:30 PM6/9/20
to ClusterHAT
Hi, 
i tried the steps from your manual again after updating bootcode.bin and the CM3 module boots.

Zero keeps geving waiting for bcm..

From the logs above assuming they're from when you was trying to boot the Pi Zero it sent a start.elf which is 438936 bytes, this is the built into rpiboot start.elf for MSD which means you possibly forgot to run "sudo clusterctrl init" after moving/plugging in cables after boot, the symlink  /var/lib/clusterctrl/boot/1-1.3.3 (again based on the logs) doesn't point to the correct /var/lib/clusterctrl/nfs/pX/boot/ directory or the usbboot files are just missing from /var/lib/clusterctrl/nfs/pX/boot/ so I'd check that.

 
Op dinsdag 9 juni 2020 13:07:53 UTC+2 schreef Patrick Nooijen:
also this does not work : 

sudo cp -r /usr/share/rpiboot/msd/ /var/lib/clusterctrl/nfs/pX/boot/


As above I need to update the docs for MSD but you can now just "sudo mv /var/lib/clusterctrl/nfs/pX /var/lib/clusterctrl/nfs/pX-disabled" (or similar) and then use rpiboot to get MSD working as it doesn't need the extra files as they're built in, then "sudo mv /var/lib/clusterctrl/nfs/pX-disabled /var/lib/clusterctrl/nfs/pX" to put them back.

Chris.

Patrick Nooijen

unread,
Jun 13, 2020, 3:01:17 AM6/13/20
to ClusterHAT
I did not move the cables.
Dit run sudo clusterctrl init, but still no boot.

Linux cbridge 5.4.42-v8+ #1319 SMP PREEMPT Wed May 20 14:18:56 BST 2020 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Tue Jun 9 17:51:40 2020
pi@cbridge:~ $ sudo clusterctrl init
pi@cbridge:~ $ clusterhat on p4
pi@cbridge:~ $ tail -f /var/log/daemon.log /var/log/kern.log ==> /var/log/daemon.log <==
Jun 13 08:53:14 cbridge rpiboot[591]: Received message GetFileSize: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: File size = 438936 bytes
Jun 13 08:53:14 cbridge rpiboot[591]: Received message ReadFile: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: File read: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: libusb_bulk_transfer sent 438936 bytes; returned 0
Jun 13 08:53:14 cbridge rpiboot[591]: Received message GetFileSize: fixup.dat
Jun 13 08:53:14 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:53:14 cbridge rpiboot[591]: Cannot open file fixup.dat
Jun 13 08:53:15 cbridge rpiboot[591]: Second stage boot server done
Jun 13 08:53:16 cbridge rpiboot[591]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun 13 08:53:09 cbridge kernel: [ 324.238691] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:53:11 cbridge kernel: [ 326.359039] usb 1-1.3.1: USB disconnect, device number 17
Jun 13 08:53:13 cbridge kernel: [ 327.816807] usb 1-1.3.1: new full-speed USB device number 18 using xhci_hcd
Jun 13 08:53:13 cbridge kernel: [ 327.918700] usb 1-1.3.1: not running at top speed; connect to a high speed hub
Jun 13 08:53:13 cbridge kernel: [ 327.924695] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun 13 08:53:13 cbridge kernel: [ 327.924711] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun 13 08:53:13 cbridge kernel: [ 327.924723] usb 1-1.3.1: Product: BCM2710 Boot
Jun 13 08:53:13 cbridge kernel: [ 327.924735] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:53:13 cbridge kernel: [ 327.924794] usb 1-1.3.1: SerialNumber: Broadcom
Jun 13 08:53:14 cbridge kernel: [ 329.530496] usb 1-1.3.1: USB disconnect, device number 18
^C
pi@cbridge:~ $ clusterhat off p4
pi@cbridge:~ $ sudo clusterctrl init
pi@cbridge:~ $ clusterhat on p4
pi@cbridge:~ $ tail -f /var/log/daemon.log /var/log/kern.log
==> /var/log/daemon.log <==
Jun 13 08:53:14 cbridge rpiboot[591]: Received message GetFileSize: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: File size = 438936 bytes
Jun 13 08:53:14 cbridge rpiboot[591]: Received message ReadFile: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: File read: start.elf
Jun 13 08:53:14 cbridge rpiboot[591]: libusb_bulk_transfer sent 438936 bytes; returned 0
Jun 13 08:53:14 cbridge rpiboot[591]: Received message GetFileSize: fixup.dat
Jun 13 08:53:14 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:53:14 cbridge rpiboot[591]: Cannot open file fixup.dat
Jun 13 08:53:15 cbridge rpiboot[591]: Second stage boot server done
Jun 13 08:53:16 cbridge rpiboot[591]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun 13 08:53:11 cbridge kernel: [ 326.359039] usb 1-1.3.1: USB disconnect, device number 17
Jun 13 08:53:13 cbridge kernel: [ 327.816807] usb 1-1.3.1: new full-speed USB device number 18 using xhci_hcd
Jun 13 08:53:13 cbridge kernel: [ 327.918700] usb 1-1.3.1: not running at top speed; connect to a high speed hub
Jun 13 08:53:13 cbridge kernel: [ 327.924695] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun 13 08:53:13 cbridge kernel: [ 327.924711] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun 13 08:53:13 cbridge kernel: [ 327.924723] usb 1-1.3.1: Product: BCM2710 Boot
Jun 13 08:53:13 cbridge kernel: [ 327.924735] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:53:13 cbridge kernel: [ 327.924794] usb 1-1.3.1: SerialNumber: Broadcom
Jun 13 08:53:14 cbridge kernel: [ 329.530496] usb 1-1.3.1: USB disconnect, device number 18
Jun 13 08:54:36 cbridge kernel: [ 410.823120] usb 1-1.3: USB disconnect, device number 16
Jun 13 08:54:53 cbridge kernel: [ 428.454856] usb 1-1.3: new high-speed USB device number 19 using xhci_hcd
Jun 13 08:54:53 cbridge kernel: [ 428.556111] usb 1-1.3: New USB device found, idVendor=05e3, idProduct=0608, bcdDevice=85.36
Jun 13 08:54:53 cbridge kernel: [ 428.556127] usb 1-1.3: New USB device strings: Mfr=0, Product=1, SerialNumber=0
Jun 13 08:54:53 cbridge kernel: [ 428.556140] usb 1-1.3: Product: USB2.0 Hub
Jun 13 08:54:53 cbridge kernel: [ 428.557704] hub 1-1.3:1.0: USB hub found
Jun 13 08:54:53 cbridge kernel: [ 428.558013] hub 1-1.3:1.0: 4 ports detected

==> /var/log/daemon.log <==
Jun 13 08:54:53 cbridge rpiboot[591]: libusb: error [udev_hotplug_event] ignoring udev action bind

==> /var/log/kern.log <==
Jun 13 08:54:54 cbridge kernel: [ 428.846883] usb 1-1.3.1: new full-speed USB device number 20 using xhci_hcd
Jun 13 08:54:54 cbridge kernel: [ 428.952688] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00
Jun 13 08:54:54 cbridge kernel: [ 428.952705] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 13 08:54:54 cbridge kernel: [ 428.952718] usb 1-1.3.1: Product: BCM2708 Boot
Jun 13 08:54:54 cbridge kernel: [ 428.952730] usb 1-1.3.1: Manufacturer: Broadcom

==> /var/log/daemon.log <==
Jun 13 08:54:54 cbridge rpiboot[591]: Device located successfully
Jun 13 08:54:54 cbridge rpiboot[591]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun 13 08:54:55 cbridge rpiboot[591]: Initialised device correctly
Jun 13 08:54:55 cbridge rpiboot[591]: Found serial number 0
Jun 13 08:54:55 cbridge rpiboot[591]: Sending bootcode.bin
Jun 13 08:54:55 cbridge rpiboot[591]: libusb_bulk_transfer sent 24 bytes; returned 0
Jun 13 08:54:55 cbridge rpiboot[591]: Writing 52304 bytes
Jun 13 08:54:55 cbridge rpiboot[591]: libusb_bulk_transfer sent 52304 bytes; returned 0
Jun 13 08:54:56 cbridge rpiboot[591]: Failed : 0x0

==> /var/log/kern.log <==
Jun 13 08:54:56 cbridge kernel: [ 431.072700] usb 1-1.3.1: USB disconnect, device number 20

==> /var/log/daemon.log <==
Jun 13 08:54:57 cbridge rpiboot[591]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun 13 08:54:57 cbridge kernel: [ 432.534884] usb 1-1.3.1: new full-speed USB device number 21 using xhci_hcd
Jun 13 08:54:57 cbridge kernel: [ 432.636726] usb 1-1.3.1: not running at top speed; connect to a high speed hub
Jun 13 08:54:58 cbridge kernel: [ 432.644729] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun 13 08:54:58 cbridge kernel: [ 432.644743] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun 13 08:54:58 cbridge kernel: [ 432.644753] usb 1-1.3.1: Product: BCM2710 Boot
Jun 13 08:54:58 cbridge kernel: [ 432.644762] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:54:58 cbridge kernel: [ 432.644771] usb 1-1.3.1: SerialNumber: Broadcom

==> /var/log/daemon.log <==
Jun 13 08:54:58 cbridge rpiboot[591]: Device located successfully
Jun 13 08:54:58 cbridge rpiboot[591]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun 13 08:54:59 cbridge rpiboot[591]: Initialised device correctly
Jun 13 08:54:59 cbridge rpiboot[591]: Found serial number 1
Jun 13 08:54:59 cbridge rpiboot[591]: Second stage boot server
Jun 13 08:54:59 cbridge rpiboot[591]: Received message GetFileSize: autoboot.txt
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:54:59 cbridge rpiboot[591]: Cannot open file autoboot.txt
Jun 13 08:54:59 cbridge rpiboot[591]: Received message GetFileSize: config.txt
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:54:59 cbridge rpiboot[591]: Cannot open file config.txt
Jun 13 08:54:59 cbridge rpiboot[591]: Received message GetFileSize: recovery.elf
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:54:59 cbridge rpiboot[591]: Cannot open file recovery.elf
Jun 13 08:54:59 cbridge rpiboot[591]: Received message GetFileSize: start.elf
Jun 13 08:54:59 cbridge rpiboot[591]: File size = 438936 bytes
Jun 13 08:54:59 cbridge rpiboot[591]: Received message ReadFile: start.elf
Jun 13 08:54:59 cbridge rpiboot[591]: File read: start.elf
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 438936 bytes; returned 0
Jun 13 08:54:59 cbridge rpiboot[591]: Received message GetFileSize: fixup.dat
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:54:59 cbridge rpiboot[591]: Cannot open file fixup.dat

==> /var/log/kern.log <==
Jun 13 08:54:59 cbridge kernel: [ 434.249157] usb 1-1.3.1: USB disconnect, device number 21

==> /var/log/daemon.log <==
Jun 13 08:55:00 cbridge rpiboot[591]: Second stage boot server done
Jun 13 08:55:01 cbridge rpiboot[591]: Waiting for BCM2835/6/7/2711...
^C
pi@cbridge:~ $ sudo rm /var/lib/clusterctrl/boot/bootcode.bin
pi@cbridge:~ $ sudo wget -O /var/lib/clusterctrl/boot/bootcode.bin https://github.com/Hexxeh/rpi-firmware/raw/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin
--2020-06-13 08:56:20-- https://github.com/Hexxeh/rpi-firmware/raw/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin
Herleiden van github.com (github.com)... 140.82.118.3
Verbinding maken met github.com (github.com)|140.82.118.3|:443... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 302 Found
Locatie: https://raw.githubusercontent.com/Hexxeh/rpi-firmware/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin [volgen...]
--2020-06-13 08:56:21-- https://raw.githubusercontent.com/Hexxeh/rpi-firmware/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin
Herleiden van raw.githubusercontent.com (raw.githubusercontent.com)... 151.101.36.133
Verbinding maken met raw.githubusercontent.com (raw.githubusercontent.com)|151.101.36.133|:443... verbonden.
HTTP-verzoek is verzonden; wachten op antwoord... 200 OK
Lengte: 52304 (51K) [application/octet-stream]
Wordt opgeslagen als: ‘/var/lib/clusterctrl/boot/bootcode.bin’

/var/lib/clusterctrl 100%[=====================>] 51,08K --.-KB/s in 0,03s

2020-06-13 08:56:21 (1,82 MB/s) - '‘/var/lib/clusterctrl/boot/bootcode.bin’' opgeslagen [52304/52304]

pi@cbridge:~ $ sudo service clusterctrl-rpiboot restart
pi@cbridge:~ $ clusterhat off p4 pi@cbridge:~ $ clusterhat on p4 pi@cbridge:~ $ tail -f /var/log/daemon.log /var/log/kern.log ==> /var/log/daemon.log <==
Jun 13 08:54:59 cbridge rpiboot[591]: libusb_bulk_transfer sent 0 bytes; returned 0Jun 13 08:54:59 cbridge rpiboot[591]: Cannot open file fixup.dat
Jun 13 08:55:00 cbridge rpiboot[591]: Second stage boot server done
Jun 13 08:55:01 cbridge rpiboot[591]: Waiting for BCM2835/6/7/2711...
Jun 13 08:56:24 cbridge systemd[1]: Stopping ClusterCTRL rpiboot for SD cardless booting...
Jun 13 08:56:24 cbridge systemd[1]: clusterctrl-rpiboot.service: Main process exited, code=killed, status=15/TERM
Jun 13 08:56:24 cbridge systemd[1]: clusterctrl-rpiboot.service: Succeeded.
Jun 13 08:56:24 cbridge systemd[1]: Stopped ClusterCTRL rpiboot for SD cardless booting.
Jun 13 08:56:24 cbridge systemd[1]: Started ClusterCTRL rpiboot for SD cardless booting.
Jun 13 08:56:24 cbridge rpiboot[1786]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun 13 08:54:54 cbridge kernel: [ 428.952730] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:54:56 cbridge kernel: [ 431.072700] usb 1-1.3.1: USB disconnect, device number 20
Jun 13 08:54:57 cbridge kernel: [ 432.534884] usb 1-1.3.1: new full-speed USB device number 21 using xhci_hcd
Jun 13 08:54:57 cbridge kernel: [ 432.636726] usb 1-1.3.1: not running at top speed; connect to a high speed hub
Jun 13 08:54:58 cbridge kernel: [ 432.644729] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun 13 08:54:58 cbridge kernel: [ 432.644743] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun 13 08:54:58 cbridge kernel: [ 432.644753] usb 1-1.3.1: Product: BCM2710 Boot
Jun 13 08:54:58 cbridge kernel: [ 432.644762] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:54:58 cbridge kernel: [ 432.644771] usb 1-1.3.1: SerialNumber: Broadcom
Jun 13 08:54:59 cbridge kernel: [ 434.249157] usb 1-1.3.1: USB disconnect, device number 21
Jun 13 08:56:43 cbridge kernel: [ 537.768327] usb 1-1.3.1: new full-speed USB device number 22 using xhci_hcd
Jun 13 08:56:43 cbridge kernel: [ 537.874242] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2763, bcdDevice= 0.00
Jun 13 08:56:43 cbridge kernel: [ 537.874259] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Jun 13 08:56:43 cbridge kernel: [ 537.874272] usb 1-1.3.1: Product: BCM2708 Boot
Jun 13 08:56:43 cbridge kernel: [ 537.874284] usb 1-1.3.1: Manufacturer: Broadcom

==> /var/log/daemon.log <==
Jun 13 08:56:43 cbridge rpiboot[1786]: Device located successfully
Jun 13 08:56:43 cbridge rpiboot[1786]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun 13 08:56:44 cbridge rpiboot[1786]: Initialised device correctly
Jun 13 08:56:44 cbridge rpiboot[1786]: Found serial number 0
Jun 13 08:56:44 cbridge rpiboot[1786]: Sending bootcode.bin
Jun 13 08:56:44 cbridge rpiboot[1786]: libusb_bulk_transfer sent 24 bytes; returned 0
Jun 13 08:56:44 cbridge rpiboot[1786]: Writing 52304 bytes
Jun 13 08:56:44 cbridge rpiboot[1786]: libusb_bulk_transfer sent 52304 bytes; returned 0
Jun 13 08:56:45 cbridge rpiboot[1786]: Failed : 0x0

==> /var/log/kern.log <==
Jun 13 08:56:45 cbridge kernel: [ 539.993959] usb 1-1.3.1: USB disconnect, device number 22

==> /var/log/daemon.log <==
Jun 13 08:56:46 cbridge rpiboot[1786]: Waiting for BCM2835/6/7/2711...

==> /var/log/kern.log <==
Jun 13 08:56:46 cbridge kernel: [ 541.352365] usb 1-1.3.1: new full-speed USB device number 23 using xhci_hcd
Jun 13 08:56:46 cbridge kernel: [ 541.454282] usb 1-1.3.1: not running at top speed; connect to a high speed hub
Jun 13 08:56:46 cbridge kernel: [ 541.460288] usb 1-1.3.1: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Jun 13 08:56:46 cbridge kernel: [ 541.460337] usb 1-1.3.1: New USB device strings: Mfr=1, Product=2, SerialNumber=1
Jun 13 08:56:46 cbridge kernel: [ 541.460350] usb 1-1.3.1: Product: BCM2710 Boot
Jun 13 08:56:46 cbridge kernel: [ 541.460361] usb 1-1.3.1: Manufacturer: Broadcom
Jun 13 08:56:46 cbridge kernel: [ 541.460372] usb 1-1.3.1: SerialNumber: Broadcom

==> /var/log/daemon.log <==
Jun 13 08:56:46 cbridge rpiboot[1786]: Device located successfully
Jun 13 08:56:46 cbridge rpiboot[1786]: libusb: error [udev_hotplug_event] ignoring udev action bind
Jun 13 08:56:47 cbridge rpiboot[1786]: Initialised device correctly
Jun 13 08:56:47 cbridge rpiboot[1786]: Found serial number 1
Jun 13 08:56:47 cbridge rpiboot[1786]: Second stage boot server
Jun 13 08:56:47 cbridge rpiboot[1786]: Received message GetFileSize: autoboot.txt
Jun 13 08:56:47 cbridge rpiboot[1786]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun 13 08:56:47 cbridge rpiboot[1786]: Cannot open file autoboot.txt
Jun 13 08:56:47 cbridge rpiboot[1786]: Received message GetFileSize: config.txt
Jun 13 08:56:47 cbridge rpiboot[1786]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun 13 08:56:47 cbridge rpiboot[1786]: Cannot open file config.txt
Jun 13 08:56:47 cbridge rpiboot[1786]: Received message GetFileSize: recovery.elf
Jun 13 08:56:47 cbridge rpiboot[1786]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun 13 08:56:47 cbridge rpiboot[1786]: Cannot open file recovery.elf
Jun 13 08:56:47 cbridge rpiboot[1786]: Received message GetFileSize: start.elf
Jun 13 08:56:47 cbridge rpiboot[1786]: File size = 438936 bytes
Jun 13 08:56:47 cbridge rpiboot[1786]: Received message ReadFile: start.elf
Jun 13 08:56:47 cbridge rpiboot[1786]: File read: start.elf
Jun 13 08:56:48 cbridge rpiboot[1786]: libusb_bulk_transfer sent 438936 bytes; returned 0
Jun 13 08:56:48 cbridge rpiboot[1786]: Received message GetFileSize: fixup.dat
Jun 13 08:56:48 cbridge rpiboot[1786]: libusb_bulk_transfer sent 0 bytes; returned 0
Jun 13 08:56:48 cbridge rpiboot[1786]: Cannot open file fixup.dat

==> /var/log/kern.log <==
Jun 13 08:56:48 cbridge kernel: [ 543.066467] usb 1-1.3.1: USB disconnect, device number 23

==> /var/log/daemon.log <==
Jun 13 08:56:49 cbridge rpiboot[1786]: Second stage boot server done
Jun 13 08:56:50 cbridge rpiboot[1786]: Waiting for BCM2835/6/7/2711...

Patrick Nooijen

unread,
Jun 13, 2020, 3:17:50 AM6/13/20
to ClusterHAT

pi@cbridge:/var/lib/clusterctrl/boot $ ls -l
totaal 52
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-1.3.1 -> /var/lib/clusterctrl/nfs/p4/boot/
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-1.3.2 -> /var/lib/clusterctrl/nfs/p3/boot/
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-1.3.3 -> /var/lib/clusterctrl/nfs/p2/boot/
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-1.3.4 -> /var/lib/clusterctrl/nfs/p1/boot/
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-1.4.2 -> /var/lib/clusterctrl/nfs/p7/boot/
lrwxrwxrwx 1 root root 33 jun 13 08:54 1-

Patrick Nooijen

unread,
Jun 13, 2020, 3:21:20 AM6/13/20
to ClusterHAT
I replaced the bootcode again and now they boot? Will test more this weekend

Chris Burton

unread,
Jun 24, 2020, 5:47:44 PM6/24/20
to ClusterHAT

Hi,

 I've uploaded updated test 64 bit versions on https://dist.8086.net/clusterctrl/testing/ and I've added a usbboot version.

 

TEST_ClusterCTRL-2020-05-27-std-64-2-CBRIDGE.img.xz - Pi 2/3/4 controller

TEST_ClusterCTRL-2020-05-27-std-64-2-CNAT.img.xz - Pi 2/3/4 controller

TEST_ClusterCTRL-2020-05-27-std-64-2-p1.img.xz - CM3/CM3+/3A+ node

TEST_ClusterCTRL-2020-05-27-std-64-2-usbboot.tar.xz - CM3/CM3+/3A+ node

 

Please let me know of any problems or success with these.

 

Thanks,

 Chris.

bowguy

unread,
Aug 26, 2020, 7:25:51 PM8/26/20
to ClusterHAT
What 64 bit image should I use for CM3+ to boot off of EMMC?  Right now the clusterctrl is your 64 bit image but the CM3+ are running your 32 bit ones.  There is a new (8/20) 64 bit lite image.

Chris Burton

unread,
Aug 26, 2020, 9:01:32 PM8/26/20
to ClusterHAT
Hi,
What 64 bit image should I use for CM3+ to boot off of EMMC?  Right now the clusterctrl is your 64 bit image but the CM3+ are running your 32 bit ones.  There is a new (8/20) 64 bit lite image.

Ah, I didn't spot that hidden away in the forum thread - If you want 64 bit lite you can try ClusterCTRL-2020-08-20-lite-64-1-p1.img.bz2 in  https://dist.8086.net/clusterctrl/testing/ it's fresh and untested the rest should hopefully appear tomorrow (err later today).

Chris.

Bruce Rindahl

unread,
Aug 26, 2020, 9:12:17 PM8/26/20
to clust...@googlegroups.com
Thanks! I'll give a try and let you know.
p.s.  I did the time zone math and thought, is he still up??

--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/clusterhat/7e046a21-b3a0-4b74-80dc-d1fbecdbcf82n%40googlegroups.com.

Bruce Rindahl

unread,
Aug 27, 2020, 12:48:13 AM8/27/20
to clust...@googlegroups.com
I cannot see the CM as a MSD per:

Log shows:
==> /var/log/kern.log <==
Aug 26 21:33:08 pi3ch kernel: [   24.689132] NFSD: starting 90-second grace period (net f00004c1)
Aug 26 21:33:11 pi3ch kernel: [   27.365913] broken atomic modeset userspace detected, disabling atomic
Aug 26 21:33:14 pi3ch kernel: [   30.005803] fuse: init (API version 7.31)
Aug 26 21:36:58 pi3ch kernel: [  241.431543] usb 1-1.4.4: USB disconnect, device number 9
Aug 26 21:37:54 pi3ch kernel: [  297.718182] usb 1-1.4.4: new high-speed USB device number 10 using dwc_otg
Aug 26 21:37:54 pi3ch kernel: [  297.818887] usb 1-1.4.4: config index 0 descriptor too short (expected 55, got 32)
Aug 26 21:37:54 pi3ch kernel: [  297.819603] usb 1-1.4.4: New USB device found, idVendor=0a5c, idProduct=2764, bcdDevice= 0.00
Aug 26 21:37:54 pi3ch kernel: [  297.819622] usb 1-1.4.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
Aug 26 21:37:54 pi3ch kernel: [  297.819639] usb 1-1.4.4: Product: BCM2710 Boot
Aug 26 21:37:54 pi3ch kernel: [  297.819655] usb 1-1.4.4: Manufacturer: Broadcom

==> /var/log/daemon.log <==
Aug 26 21:33:15 pi3ch systemd[988]: Starting Virtual filesystem service - digital camera monitor...
Aug 26 21:33:15 pi3ch dbus-daemon[1037]: [session uid=1000 pid=1037] Successfully activated service 'org.gtk.vfs.GPhoto2VolumeMonitor'
Aug 26 21:33:15 pi3ch systemd[988]: Started Virtual filesystem service - digital camera monitor.
Aug 26 21:33:15 pi3ch dbus-daemon[1037]: [session uid=1000 pid=1037] Activating via systemd: service name='org.gtk.vfs.MTPVolumeMonitor' unit='gvfs-mtp-volume-monitor.service' requested by ':1.7' (uid=1000 pid=1098 comm="pcmanfm --desktop --profile LXDE-pi ")
Aug 26 21:33:15 pi3ch systemd[988]: Starting Virtual filesystem service - Media Transfer Protocol monitor...
Aug 26 21:33:15 pi3ch dbus-daemon[1037]: [session uid=1000 pid=1037] Successfully activated service 'org.gtk.vfs.MTPVolumeMonitor'
Aug 26 21:33:15 pi3ch systemd[988]: Started Virtual filesystem service - Media Transfer Protocol monitor.
Aug 26 21:33:24 pi3ch systemd[1]: systemd-fsckd.service: Succeeded.
Aug 26 21:33:44 pi3ch systemd[1]: systemd-hostnamed.service: Succeeded.
Aug 26 21:34:25 pi3ch systemd[1]: Started Session c3 of user pi.

But no sdY in /dev


Chris Burton

unread,
Aug 27, 2020, 6:47:39 AM8/27/20
to ClusterHAT
Hi,
From the logs it doesn't look like rpiboot is running (it doesn't run if there's not device detected at boot time).

I've advise running these commands (replacing bootcode.bin with an old version if you haven't already as recent versions still don't work) and then try again.

sudo rm /var/lib/clusterctrl/boot/bootcode.bin

sudo wget -O /var/lib/clusterctrl/boot/bootcode.bin https://github.com/Hexxeh/rpi-firmware/raw/b524f5e7ace11ed7500fc39e63247fe9756fbddf/bootcode.bin
sudo service clusterctrl-rpiboot restart    

Chris. 

Bruce Rindahl

unread,
Aug 27, 2020, 9:34:23 AM8/27/20
to clust...@googlegroups.com
Following the directions I get:

sudo service clusterctrl-rpiboot restart
A dependency job for clusterctrl-rpiboot.service failed. See 'journalctl -xe' for details.
pi@pi3ch:~ $ journalctl -xe
--
-- The job identifier is 884.
Aug 27 06:22:55 pi3ch systemd[1]: if...@ethpi5.service: Succeeded.
-- Subject: Unit succeeded
-- Defined-By: systemd
--
-- The unit if...@ethpi5.service has successfully entered the 'dead' state.
Aug 27 06:22:55 pi3ch systemd[1]: Stopped ifup for ethpi5.
-- Subject: A stop job for unit if...@ethpi5.service has finished
-- Defined-By: systemd
--
-- A stop job for unit if...@ethpi5.service has finished.
--
-- The job identifier is 884 and the job result is done.
Aug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: new high-speed USB device number 10 using dwc_otgAug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: config index 0 descriptor too short (expected 55,Aug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: New USB device found, idVendor=0a5c, idProduct=27Aug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: New USB device strings: Mfr=1, Product=2, SerialNAug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: Product: BCM2710 Boot
Aug 27 06:24:35 pi3ch kernel: usb 1-1.4.4: Manufacturer: Broadcom
Aug 27 06:24:35 pi3ch mtp-probe[1459]: checking bus 1, device 10: "/sys/devices/platform/socAug 27 06:24:35 pi3ch mtp-probe[1459]: bus: 1, device: 10 was not an MTP device
Aug 27 06:24:35 pi3ch mtp-probe[1460]: checking bus 1, device 10: "/sys/devices/platform/socAug 27 06:24:35 pi3ch mtp-probe[1460]: bus: 1, device: 10 was not an MTP device
Aug 27 06:25:01 pi3ch CRON[1462]: pam_unix(cron:session): session opened for user root by (uAug 27 06:25:01 pi3ch CRON[1466]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parAug 27 06:25:01 pi3ch CRON[1462]: pam_unix(cron:session): session closed for user root
Aug 27 06:26:46 pi3ch sudo[1493]:       pi : TTY=pts/0 ; PWD=/home/pi ; USER=root ; COMMAND=Aug 27 06:26:46 pi3ch sudo[1493]: pam_unix(sudo:session): session opened for user root by piAug 27 06:26:46 pi3ch systemd[1]: ClusterCTRL init is not active.
Aug 27 06:26:46 pi3ch systemd[1]: Dependency failed for ClusterCTRL rpiboot for SD cardless -- Subject: A start job for unit clusterctrl-rpiboot.service has failed
-- Defined-By: systemd
--
-- A start job for unit clusterctrl-rpiboot.service has finished with a failure.
--
-- The job identifier is 885 and the job result is dependency.
Aug 27 06:26:46 pi3ch systemd[1]: clusterctrl-rpiboot.service: Job clusterctrl-rpiboot.serviAug 27 06:26:46 pi3ch sudo[1493]: pam_unix(sudo:session): session closed for user root

I noticed the notation about ClusterCTRL init not active so I ran:

pi@pi3ch:~ $ sudo clusterctrl init
Traceback (most recent call last):
  File "/sbin/clusterctrl", line 452, in <module>
    os.symlink(nfsroot+'p'+p+"/boot/", nfsboot+path)
OSError: [Errno 17] File exists
pi@pi3ch:~ $

Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.

Chris Burton

unread,
Aug 27, 2020, 2:36:18 PM8/27/20
to ClusterHAT
Hi, 
pi@pi3ch:~ $ sudo clusterctrl init
Traceback (most recent call last):
  File "/sbin/clusterctrl", line 452, in <module>
    os.symlink(nfsroot+'p'+p+"/boot/", nfsboot+path)
OSError: [Errno 17] File exists
pi@pi3ch:~ $

What does "ls -l /var/lib/clusterctrl/boot/" show?

You should only see a bootcode.bin file and anything else in there should be symlinks into "../nfs/pX/boot/" but from the error it looks like you might have a directory/file with the same name as the USB device (so 1-x.x.x type thing) it's trying to create a link for.

If this is the case I'd remove (or rename it) and try restarting the service again.

Chris.

Bruce Rindahl

unread,
Aug 27, 2020, 4:35:10 PM8/27/20
to clust...@googlegroups.com
Nothing there except bootcode.bin

pi@pi3ch:~ $ ls -l /var/lib/clusterctrl/boot/
total 52
-rw-r--r-- 1 root root 52304 Aug 27 06:16 bootcode.bin
pi@pi3ch:~ $


--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.

Chris Burton

unread,
Aug 28, 2020, 3:51:19 AM8/28/20
to ClusterHAT
Hi,
Nothing there except bootcode.bin

OK - can you try unplugging the ClusterCTRL Stack and then try the restart the service (the Stack doesn't have USB devices so I'm wondering if this is confusing it).

Thanks,
 Chris.

Chris Burton

unread,
Aug 28, 2020, 7:26:21 AM8/28/20
to ClusterHAT
Hi, 
Nothing there except bootcode.bin

OK - can you try unplugging the ClusterCTRL Stack and then try the restart the service (the Stack doesn't have USB devices so I'm wondering if this is confusing it).

I've confirmed this is the issue, I've pushed an update for this bug to github. You can manually update it with these two commands.


It should then skip trying to create the symlinks for the ClusterCTRL Stack (which doesn't have any "USB path" data) and the service should start OK.

Chris. 

Bruce Rindahl

unread,
Aug 28, 2020, 2:09:27 PM8/28/20
to clust...@googlegroups.com
Is that image gone?  I can't find it in the testing directory. 
Thanks

--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.

Chris Burton

unread,
Aug 29, 2020, 10:43:03 AM8/29/20
to ClusterHAT
Hi,
Is that image gone?  I can't find it in the testing directory. 

Yes, I pulled it yesterday and it's now been replaced by a whole set of new testing images with the 2 bug fixes in clusterctrl (ctrl+v1 hat numbering and clusterctrl-init service issues with a stack).

Chris. 

Bruce Rindahl

unread,
Aug 29, 2020, 11:17:32 AM8/29/20
to clust...@googlegroups.com
Great!
Here is where I am.  I got the earlier version to work  ( I needed to format the EMMC).  Everything's working on 64 bit.

  Bugs:
Clusterctrl status always shows p6-p8 (triple) as off no matter what the status but u6-u8 work as expected.

The ethernet bridge to the triple does not survive a reboot of the cluster controller.  They are still running as I can connect via /dev/ttypiX but no internet, just the local address.  Reboot of the module does not work, only clusterctrl off pX / clusterctrl on pX restores the bridge.

Wish list:  It would be nice to have clusterctrl status show the state of the fans.  When I get my script working to control the fan on the triple I will turn on the LEDs for a status.  I will post the script when I get it working.

Overall these are both great products.
Thanks!






--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.

Chris Burton

unread,
Aug 29, 2020, 12:13:40 PM8/29/20
to ClusterHAT
Hi, 
  Bugs:
Clusterctrl status always shows p6-p8 (triple) as off no matter what the status but u6-u8 work as expected.

Can you try with the latest clusterctrl script.
And if you still have problems let me know everything you have plugged in (CluserHAT/ClusterCTRL devices) and the output of "clusterctrl status".
 
The ethernet bridge to the triple does not survive a reboot of the cluster controller.  They are still running as I can connect via /dev/ttypiX but no internet, just the local address.  Reboot of the module does not work, only clusterctrl off pX / clusterctrl on pX restores the bridge.

Is it the bridge that doesn't survive or dhcpcd going wonky?

What does "ifconfig -a;brctl show;lsusb -t" and "clusterctrl status" look like after rebooting? The contents of /var/log/kern.log and daemon.log since boot would probably be helpful too.

Wish list:  It would be nice to have clusterctrl status show the state of the fans.  When I get my script working to control the fan on the triple I will turn on the LEDs for a status.  I will post the script when I get it working.

 That was a bit of an oversight as there isn't a command in the firmware to retrieve the status of the fan, I do plan to add it at some point in the future though.

Chris.

Bruce Rindahl

unread,
Aug 29, 2020, 12:41:43 PM8/29/20
to clust...@googlegroups.com
Latest clusterctrl script no change.  Output of status:

pi@pi3ch:~ $ clusterctrl status
clusterhat:False
clusterctrl:2
maxpi:8
throttled:0x0
ctrl_bus:20:11:5 21:12:3
ctrl20:FW:1.5 ADC1:5136mV ADC2:11936mV T1:27.87C
p1:1
p2:1
p3:1
p4:1
p5:1
ctrl21:FW:1.2 ADC1:4518mV T1:95.90C
p6:0
u6:0
p7:0
u7:0
p8:0
u8:0

No ClusterHAT
One ClusterSTACK
One ClusterTriple - all booting from EMMC

It now survives a reboot.  I went to a fixed IP's on the compute modules and they stay connected so you are probably right about the dhcpcd going wonky.  If you want I can disable the fixed IP on one and give you the output you want.  Let me know.

Thanks




--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.

Bruce Rindahl

unread,
Aug 29, 2020, 11:31:07 PM8/29/20
to clust...@googlegroups.com
I disabled fixed IP (via /etc/dhcpcd.conf) on p6.  p7 and p8 stayed on fixed IP.  After reboot on cluster controller:

-----------------------------------------------------------------------------------
pi@pi3ch:~ $ ifconfig -a;brctl show;lsusb -t
br0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 3.14.159.140  netmask 255.255.255.0  broadcast 3.14.159.255
        inet6 fd51:42f8:caae:d92e::ff  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::81b4:f936:7d5b:e2e5  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:a4:2e:b1  txqueuelen 1000  (Ethernet)
        RX packets 104  bytes 12677 (12.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 86  bytes 10757 (10.5 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

brint: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 172.19.180.254  netmask 255.255.255.0  broadcast 172.19.180.255
        inet6 fe80::ec6a:6bff:feea:5c13  prefixlen 64  scopeid 0x20<link>
        ether ee:6a:6b:ea:5c:13  txqueuelen 1000  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 38  bytes 4726 (4.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        ether b8:27:eb:a4:2e:b1  txqueuelen 1000  (Ethernet)
        RX packets 81  bytes 10567 (10.3 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 109  bytes 14265 (13.9 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethpi6: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::222:82ff:feff:fe06  prefixlen 64  scopeid 0x20<link>
        ether 00:22:82:ff:fe:06  txqueuelen 1000  (Ethernet)
        RX packets 25  bytes 3286 (3.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 44  bytes 8542 (8.3 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethpi7: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::222:82ff:feff:fe07  prefixlen 64  scopeid 0x20<link>
        ether 00:22:82:ff:fe:07  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1818 (1.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 42  bytes 8330 (8.1 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

ethpi8: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::222:82ff:feff:fe08  prefixlen 64  scopeid 0x20<link>
        ether 00:22:82:ff:fe:08  txqueuelen 1000  (Ethernet)
        RX packets 14  bytes 1818 (1.7 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 41  bytes 8216 (8.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 7  bytes 353 (353.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 7  bytes 353 (353.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 3.14.159.4  netmask 255.255.255.0  broadcast 3.14.159.255
        inet6 fe80::e12c:fc1:3d2f:de17  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:f1:7b:e4  txqueuelen 1000  (Ethernet)
        RX packets 41  bytes 4630 (4.5 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 27  bytes 4114 (4.0 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

bridge name     bridge id               STP enabled     interfaces
br0             8000.b827eba42eb1       no              eth0
                                                        ethpi6
                                                        ethpi7
                                                        ethpi8
brint           8000.000000000000       no
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=dwc_otg/1p, 480M
    |__ Port 1: Dev 2, If 0, Class=Hub, Driver=hub/5p, 480M
        |__ Port 1: Dev 3, If 0, Class=Vendor Specific Class, Driver=smsc95xx, 480M
        |__ Port 4: Dev 4, If 0, Class=Hub, Driver=hub/4p, 480M
            |__ Port 4: Dev 9, If 1, Class=CDC Data, Driver=rndis_host, 480M
            |__ Port 4: Dev 9, If 4, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 4: Dev 9, If 2, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 4: Dev 9, If 0, Class=Communications, Driver=rndis_host, 480M
            |__ Port 4: Dev 9, If 5, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 4: Dev 9, If 3, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 2: Dev 7, If 2, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 2: Dev 7, If 0, Class=Communications, Driver=rndis_host, 480M
            |__ Port 2: Dev 7, If 5, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 2: Dev 7, If 3, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 2: Dev 7, If 1, Class=CDC Data, Driver=rndis_host, 480M
            |__ Port 2: Dev 7, If 4, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 3: Dev 8, If 4, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 3: Dev 8, If 2, Class=Communications, Driver=cdc_acm, 480M
            |__ Port 3: Dev 8, If 0, Class=Communications, Driver=rndis_host, 480M
            |__ Port 3: Dev 8, If 5, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 3: Dev 8, If 3, Class=CDC Data, Driver=cdc_acm, 480M
            |__ Port 3: Dev 8, If 1, Class=CDC Data, Driver=rndis_host, 480M
            |__ Port 1: Dev 6, If 0, Class=, Driver=i2c-tiny-usb, 1.5M
        |__ Port 5: Dev 5, If 0, Class=, Driver=i2c-tiny-usb, 1.5M
pi@pi3ch:~ $ ssh p...@p6.local
^C
pi@pi3ch:~ $ ssh p...@p7.local
p...@p7.local's password:
Linux p7 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Aug 29 20:08:14 2020 from 3.14.159.140
pi@p7:~ $ exit
logout
Connection to p7.local closed.
pi@pi3ch:~ $ ssh p...@p8.local
p...@p8.local's password:
Linux p8 5.4.51-v8+ #1333 SMP PREEMPT Mon Aug 10 16:58:35 BST 2020 aarch64

The programs included with the Debian GNU/Linux system are free software;
the exact distribution terms for each program are described in the
individual files in /usr/share/doc/*/copyright.

Debian GNU/Linux comes with ABSOLUTELY NO WARRANTY, to the extent
permitted by applicable law.
Last login: Sat Aug 29 20:08:52 2020 from 3.14.159.140
pi@p8:~ $ exit
logout
Connection to p8.local closed.

pi@pi3ch:~ $ clusterctrl status
clusterhat:False
clusterctrl:2
maxpi:8
throttled:0x0
ctrl_bus:20:11:5 21:12:3
ctrl20:FW:1.5 ADC1:5124mV ADC2:11969mV T1:27.87C
p1:1
p2:1
p3:1
p4:1
p5:1
ctrl21:FW:1.2 ADC1:4273mV T1:99.18C
p6:0
u6:0
p7:0
u7:0
p8:0
u8:0
pi@pi3ch:~ $
---------------------------------------------------------

Note I can still do ssh p...@pX.local on p7 and p8 but not p6

Logs attached




--
You received this message because you are subscribed to a topic in the Google Groups "ClusterHAT" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/clusterhat/h4EFRcbUJJs/unsubscribe.
To unsubscribe from this group and all its topics, send an email to clusterhat+...@googlegroups.com.
kern.log
daemon.log

Chris Burton

unread,
Aug 30, 2020, 8:37:18 AM8/30/20
to ClusterHAT
Hi, 
Note I can still do ssh p...@pX.local on p7 and p8 but not p6

Logs attached

Thanks for the logs, I think I can replicate the issue here.

Adding "reboot 15" towards the top of the /etc/dhcpcd.conf file on the nodes CM/Pi Zeros/etc. fixes it for me, I'd be grateful if you could give it a try when using DHCP.

It should make it wait a little longer before giving up on DHCP before using the fallback IP (even when it's not rebooting itself).
 
Chris.

Bruce Rindahl

unread,
Aug 30, 2020, 10:36:34 AM8/30/20
to clust...@googlegroups.com
That fixed the reboot on mine as well for DHCP.  I need fixed IP's though so I reverted back.  Thanks as always for the great support.

Keith

unread,
Oct 30, 2020, 12:12:21 PM10/30/20
to clust...@googlegroups.com
Hi All
 
I am using image 2020-08-20-8-ClusterCTRL-armhf-full-CBRIDGE and every thing seemed to load fine and the Pi booted up OK. the problem is “clusterctrl status” produces “ERROR: No ClusterHAT/CTRL device found”, I notice on boot up that I get “Failed to start ClusterCTRL.init”. Have I made an error  or missed something somewhere?
 
Regard Keith Ray

Virus-free. www.avg.com
Reply all
Reply to author
Forward
0 new messages