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

deekerman commented

2026-02-20 13:18:29 -05:00

Owner

Originally created by @n1nj4888 on GitHub (Feb 9, 2020).

Originally assigned to: @mdevaev on GitHub.

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

Originally created by @n1nj4888 on GitHub (Feb 9, 2020). Originally assigned to: @mdevaev on GitHub. 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](https://github.com/pikvm/docs/files/4178657/A-dmesg-pi4-with-USBC-power.txt) [B-dmesg-pi4-with-PoE-power.txt](https://github.com/pikvm/docs/files/4178660/B-dmesg-pi4-with-PoE-power.txt)

deekerman

2026-02-20 13:18:29 -05:00

closed this issue
added the
type:bug

component:documentation

resolution:fixed
labels

deekerman commented

2026-02-20 13:18:31 -05:00

Author

Owner

@mdevaev commented on GitHub (Feb 13, 2020):

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.

@mdevaev commented on GitHub (Feb 13, 2020): 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.

deekerman commented

2026-02-20 13:18:31 -05:00

Author

Owner

@orbatschow commented on GitHub (Aug 1, 2020):

@n1nj4888

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

@orbatschow commented on GitHub (Aug 1, 2020): @n1nj4888 Im using this POE hat without any issues: https://smile.amazon.de/gp/product/B07JPXR9ZN?psc=1

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@wahooli commented on GitHub (Aug 13, 2020):

@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.

@wahooli commented on GitHub (Aug 13, 2020): @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.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@6by9 commented on GitHub (Oct 5, 2020):

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.

@6by9 commented on GitHub (Oct 5, 2020): 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.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@mdevaev commented on GitHub (Oct 5, 2020):

@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?

@mdevaev commented on GitHub (Oct 5, 2020): @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?

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@6by9 commented on GitHub (Oct 5, 2020):

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.

@6by9 commented on GitHub (Oct 5, 2020): I dropped in as a [forum post](https://www.raspberrypi.org/forums/viewtopic.php?f=98&t=287376) 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](https://github.com/raspberrypi/linux/blob/rpi-5.4.y/drivers/hwmon/rpi-poe-fan.c#L151) call and sensor attribute. That appears to be passed across to the HAT, so is presumably stored in flash.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@mdevaev commented on GitHub (Oct 17, 2020):

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

@mdevaev commented on GitHub (Oct 17, 2020): Okay, I documented the solution, thank you all :)

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@itchy2 commented on GitHub (Sep 26, 2021):

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

@itchy2 commented on GitHub (Sep 26, 2021): Is this issue still valid in the latest version? I am thinking about buying a Poe with fan.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@mdevaev commented on GitHub (Sep 27, 2021):

I don't know. Perhaps yes.

@mdevaev commented on GitHub (Sep 27, 2021): I don't know. Perhaps yes.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@jpdsc commented on GitHub (May 1, 2022):

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.

@jpdsc commented on GitHub (May 1, 2022): 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.

deekerman commented

2026-02-20 13:18:32 -05:00

Author

Owner

@mdevaev commented on GitHub (May 1, 2022):

Is it a new revision?

@mdevaev commented on GitHub (May 1, 2022): Is it a new revision?

deekerman commented

2026-02-20 13:18:33 -05:00

Author

Owner

@jpdsc commented on GitHub (May 1, 2022):

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)

@jpdsc commented on GitHub (May 1, 2022): > 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)

deekerman commented

2026-02-20 13:18:33 -05:00

Author

Owner

@6by9 commented on GitHub (May 1, 2022):

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 https://github.com/raspberrypi/linux/pull/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.

@6by9 commented on GitHub (May 1, 2022): 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 https://github.com/raspberrypi/linux/pull/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.

deekerman commented

2026-02-20 13:18:33 -05:00

Author

Owner

@jpdsc commented on GitHub (May 1, 2022):

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?

@jpdsc commented on GitHub (May 1, 2022): > 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](https://github.com/raspberrypi/linux/pull/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?

deekerman commented

2026-02-20 13:18:33 -05:00

Author

Owner

@VoeGalore commented on GitHub (May 1, 2022):

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 https://github.com/pikvm/pikvm/issues/6#issuecomment-1114247929 if your kernel is newer than 2022-Jan-20 then no worries, otherwise upgrade.

@VoeGalore commented on GitHub (May 1, 2022): > > 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](https://github.com/raspberrypi/linux/pull/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 https://github.com/pikvm/pikvm/issues/6#issuecomment-1114247929 if your kernel is newer than 2022-Jan-20 then no worries, otherwise upgrade.

deekerman commented

2026-02-20 13:18:33 -05:00

Author

Owner

@rufo commented on GitHub (Aug 5, 2022):

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.)

@rufo commented on GitHub (Aug 5, 2022): 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.)

deekerman referenced this issue

2026-02-20 13:18:37 -05:00

Why splitting the USB cable for RPI4? Works flawlessly without #11

deekerman referenced this issue

2026-02-20 13:59:32 -05:00

[SOLVED] UEFI setup screen broken with ASRock H670 PG Riptide #457

Rows
Columns

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