Pikvm with Pi4 powered by PoE Hat does not seem to find the auvidea B101

[n1nj4888]

Hi There,

I can successfully log into pikvm and stream video using the B101 HDMI->CSI adapter on a pi4 when USB-C powered but when I try the same setup (same SD card, B101, input host etc) but with the pi4 powered using a PoE Hat rather than USB-C power, it appears pikvm cannot find the B101 when booting (even though the B101 green power light is enabled indicating the B101 is being powered)...

I've attached the dmesg boot output from when (A) pi4 powered by USB-C and (b) pi4 powered by PoE Hat.

When the pi4 boots with USB-C power, I get the following type of messages in dmesg:

[    9.190789] tc358743 0-000f: tc358743 found @ 0x1e (bcm2835 I2C adapter)

When the pi4 boots with PoE Hat power, I get the following type of messages in dmesg:

[     10.002996] tc358743 0-000f: i2c_rd: reading register 0x0 from 0xf   failed
[     10.010416] tc358743 0-000f: not a TC358743 on address 0x1e

Thanks for taking the time to take a look!
A-dmesg-pi4-with-USBC-power.txt
B-dmesg-pi4-with-PoE-power.txt

[mdevaev]

Apparently the reason is that PoE Hat takes the I2C address that B101 wants to use. PoE Hat uses I2C to control the fan. I don't know of a simple solution to resolve the address conflict. A quick search didn't yield any results. As a temporary solution, I may suggest you to bend pins responsible for connecting the I2C to the PoE Hat and turn the fan directly to the 5V power pin so that it is always on.

[orbatschow]

@n1nj4888

Im using this POE hat without any issues: https://smile.amazon.de/gp/product/B07JPXR9ZN?psc=1

[wahooli]

@orbatschow
I bought exactly same board, but I'm getting same message in dmesg output. Have you configured something else?

For noobs like me, what pins exactly I should bend?

EDIT: apparently I had faulty hardware, works with before mentioned POE hat.

[6by9]

It's not an I2C address issue, but one of pinmuxing.

The PoE HAT fan is controlled via BSC0 on GPIOs 0&1 via the firmware. The TC358743 is controlled by BSC0 on typically GPIOs 44&45 via the kernel.
The two have no knowledge of one another, therefore once the firmware first wants to update the fan settings and updated the pinmuxing (it always makes sure the muxing is right first), then you won't be able to communicate with the TC358743 again.

Disable the fan control by blacklisting "rpi-poe-fan".
You could disable it via DT, but that gets trickier as the config comes from the HAT EEPROM.

The 5.4 kernel does have support in for using the i2c_mux_pinctrl overlay to expose both those pinmuxings at the same time as i2c-0 and i2c-10. It remembers the last setting though, so repeated accesses to i2c-10 won't attempt to change the pinmuxing. It is possible to set an idle state which may restore things for you.
You've still got the potential for the 2 processors (ARM and VPU) to decide to do i2C transactions simultaneously though.

[mdevaev]

@6by9 Glad to see you here :)

Thank you for this information. By the way, do you know what will happen with the fan when the module is blacklisted? Will it always be on, or won't it work at all?

[6by9]

I dropped in as a forum post linked here. It looks quite a neat setup.

A quick read of the firmware source reveals config.txt property disable_poe_fan=1 to not open the fan driver - easier than blacklisting modules.

Pass as to the fan setting without the module. It'll probably be the default you get on first powering up the module.
Reading the driver there is a set_def_pwm call and sensor attribute. That appears to be passed across to the HAT, so is presumably stored in flash.

[mdevaev]

Okay, I documented the solution, thank you all :)

[itchy2]

Is this issue still valid in the latest version? I am thinking about buying a Poe with fan.

[mdevaev]

I don't know. Perhaps yes.

[jpdsc]

Want to share some additional information from my current setup and experience.

I have a Pi4 2GB
PoE+ HAT: https://www.raspberrypi.com/products/poe-plus-hat/
CSI-2: https://www.amazon.nl/-/en/gp/product/B0899L6ZXZ/ref=ppx_yo_dt_b_asin_title_o06_s00?ie=UTF8&psc=1
PortaPow USB Power Blocker

I do not have the mentioned issues. Checked dmesg and no error as stated above.

What I did do was edit config.txt to lower the PoE fan RPM VS TEMP

# PoE Hat Fan Speeds
dtparam=poe_fan_temp0=50000
dtparam=poe_fan_temp1=60000
dtparam=poe_fan_temp2=70000
dtparam=poe_fan_temp3=80000

I don't think this has any influence.

[mdevaev]

Is it a new revision?

[jpdsc]

Is it a new revision?

It's a newer version of the PoE HAT, not sure if it's classified as revision as the changes are quite a lot:
https://www.hackster.io/kamal-khan/raspberry-pi-poe-hat-vs-poe-hat-specifications-718cac

Looking at the post date from OP it seems like OP has the PoE HAT as the PoE+ HAT was released around 06-2021.

This means, the issue is probably still valid for PoE HAT but not for PoE+ as confirmed by me.
So if anyone wants to achieve this setup without issues I advise to buy the PoE+ HAT and not the first version (PoE HAT)

[6by9]

The PoE HAT drivers have been reworked to support either communicating via the firmware (required for the legacy camera stack), or direct over i2c-0 (for libcamera or other kernel use of i2c-0).
See raspberrypi/linux#4835

The firmware will automatically select the i2c override based on whether BSC0 (&i2c0if) is enabled or not at boot time. Enabling it dynamically will potentially cause issues.

[jpdsc]

The PoE HAT drivers have been reworked to support either communicating via the firmware (required for the legacy camera stack), or direct over i2c-0 (for libcamera or other kernel use of i2c-0). See raspberrypi/linux#4835

The firmware will automatically select the i2c override based on whether BSC0 (&i2c0if) is enabled or not at boot time. Enabling it dynamically will potentially cause issues.

So this means that using an official PoE(+) HAT with the changes they did to the drivers makes it not anymore "Not recommended" right?

[VoeGalore]

The PoE HAT drivers have been reworked to support either communicating via the firmware (required for the legacy camera stack), or direct over i2c-0 (for libcamera or other kernel use of i2c-0). See raspberrypi/linux#4835
The firmware will automatically select the i2c override based on whether BSC0 (&i2c0if) is enabled or not at boot time. Enabling it dynamically will potentially cause issues.

So this means that using an official PoE(+) HAT with the changes they did to the drivers makes it not anymore "Not recommended" right?

so I just tested a pikvm installation (v0-hdmi-rpi3-20211210.img), performed pacman -Syyu to get latest kernel upgrade (just need to be newer than 2022-Jan-20 where fix was made), using a RPi official PoE HAT (802.3af compliant) no i2c conflict, video works out of a C779 CSI bridge.

So to reference #6 (comment) if your kernel is newer than 2022-Jan-20 then no worries, otherwise upgrade.

[rufo]

To echo what VoeGalore stated, I just tried an official RPi PoE hat on a freshly updated v2 PiKVM (Pi 4 B) w/CSI bridge, and both the fan and CSI bridge are working fine. (The PoE hat is 2-3 years old I think, if that matters at all.)