Raspberry Pi PoE+ HAT not initialising

You are ahead on power management via the switch, that is pretty brilliant.

PoE fire extinguishers :laughing:

If you are going to do a Unifi API interface, you might consider adding it to https://gilesknap.github.io/maaspower. The framework is all there and instructions for adding new API support is here https://gilesknap.github.io/maaspower/main/how-to/addapi.html

(mind you if Unifi has a CLI then you are already covered)

FYI, I’m also working on building my own custom OS image for MAAS. I have it working for x86 and if I can make it work for Arm64 I may be able to base it on the official RPI ubuntu. That might help with issues like this fan problem. But I’m unclear if the UEFI will get in the way of that.

@tu630c I get the impression from your post that you worked out your own method of making RPI work with MAAS. Have you seen this https://maas.io/tutorials/build-your-own-bare-metal-cloud-using-a-raspberry-pi-cluster-with-maas#1-overview ??

I’d be interested in your comments on what you did differently from the above.


I actually followed your work (https://github.com/gilesknap/IaC-at-home/blob/main/nas/03-maas/RaspiMASS.md) and just had it up and running last night. Great job mate, first rate. Have been working on this 6 months when I stumbled on MAAS and the work being done here. Had the lab mostly up in about a week. On to solve the cooling and power issues. I am determined to operate these Pi’s with one cable.

I actually bought a UA subscription to use the private PPA to shoehorn a raspbian image into MAAS to get around the cooling issue, but to date no ubuntu rep has given me access to the private PPA that enables the maas-image-builder so I am left dismantling raspbians exec on what exactly is being done to init the new PoE hat. It is interesting the complexity of the newer PoE+ model, it even has a ready indicator to tell you that it is active.

@anton5mith Is there any chance you can help @tu630c with the PPA access he mentions above? It’s for the RPi Bramble Cause! :slight_smile:


@tu630c If you can’t get the PPA access you could also have a go at following what I’m trying - I would certainly like a 2nd pair of eyes on this https://github.com/gilesknap/IaC-at-home/tree/main/imagebuild (its been on hold for a week while I get PoE control working)

See link at the very end for progress on Arm64.

hi, for some reason I can’t see any comment there when I click that link :frowning:

Hmmm, I think I have made a confusing post. I put the link to Bramble post for tu630c’s benefit.

The query about PPAs is just above here Raspberry Pi PoE+ HAT not initialising

Oh, sorry. I am tired! I just booted a server under my desk inSweden from a MAAS-in-the-Cloud (in a GCP VM) in Australia. I’m going to write that up soon.

Anyway - about the PPA access, two things:

  1. if you paid for UA-I then you should get access to MIB. Have you contacted support and nagged them? Otherwise, PM me with your details.
  2. we are moving towards packer based images. So if you really want to do a custom image, you should try to do it with packer anyway.

Packer: that’s cool because it is what is used in my earlier link https://github.com/gilesknap/IaC-at-home/tree/main/imagebuild.

MAAS in the cloud: I want one! :slight_smile:

1 Like

We can all have a MAAS in the cloud :heart_eyes:

Does your GCP VM incur charges or does it sit under the free usage?

Spent a bit of time digging in, there is a lot of information you can glean from both the AF (2018) and AT (2021) hats, like voltage, current draw, etc. However in Raspbian they are device tree overlays that trigger from other device tree temp zones. Not possible in Ubuntu really. Maybe doable instead with a python script?

rpi-poe-fan@0 {
	cooling-levels = <0x00 0x20 0x40 0x80 0xff>;
	cooling-max-state = <0x04>;
	compatible = "raspberrypi,rpi-poe-fan";
	status = "okay";
	firmware = <0x06>;
	phandle = <0xe3>;
	cooling-min-state = <0x00>;
	#cooling-cells = <0x02>;

rpi-poe-power-supply@0 {
	compatible = "raspberrypi,rpi-poe-power-supply";
	status = "okay";
	firmware = <0x06>;
	phandle = <0xe7>;

@tu630c that looks helpful. But do you know how to do it? I’m afraid I only found out what a DTB was last week ! :slight_smile:

I should go away and read this maybe https://elinux.org/images/f/f9/Petazzoni-device-tree-dummies_0.pdf

Found a lot of useful information here:

Also was able to id the dtoverlay’s with dtc -I fs /proc/device-tree

Finally, these are all readable values being reported by the hats, so should be readable via a script. Notice how Pi foundation has the two functions broken apart. Not sure why yet.
:/proc/device-tree/rpi-poe-fan@0 $ ls
compatible '#cooling-cells' cooling-levels cooling-max-state cooling-min-state firmware name phandle status
:/proc/device-tree/rpi-poe-power-supply@0 $ ls
compatible firmware name phandle status

1 Like

It is not free because I’ve had my gcp account for a long time, and MAAS seems to have issues on a machine with only 1 GB of RAM (micro). But you can get a free account with 300 dollars of credit I think. I’m using it for a proof of concept really.

The AT model fan is being driven by PWM from the onboard Atmel Tiny814, which means it does not appear that it can be simply powered by feeding pwm to a GPIO pin. I may have to reach out to the kind people at the Pi Foundation for a shortcut to a lot of reverse engineering.

I found some useful info today from a friend at work.

There is a DT Overlay file for the PoE Hat here https://github.com/raspberrypi/firmware/blob/master/boot/overlays/rpi-poe-plus.dtbo

The drivers it refers to are in the upstream kernel.

They got added in March last year so that definitely puts them in the kernel that 22.04 is using, I’d have to check earlier versions.

I got instructions for dynamic Device Table Overlay load at runtime:

sudo su
mount -t configfs none /sys/kernel/config    # if not already mounted
mkdir -p /sys/kernel/config/device-tree/overlays/rpi-poe-plus
cat rpi-poe-plus.dtbo > /sys/kernel/config/device-tree/overlays/rpi-poe-plus/dtbo

BUT this does not work on our MAAS supplied 22.04 because dynamic overlays are disabled in the kernel.

This means that we need to modify the dtb that gets passed to boot.

It is my hope that this can be achieved with Anton’s DTB patching approach. (But I’m still unclear if that is the final DTB we end up with)