Verdin-imx8mp SMBUS/smart battery bug - backport?

Technical Support
, ,
1

While working with a smart battery/SMBUS system on a verdin IMX8MP, I encountered a problem where all I2C block reads were failing - with the symptom being that the kernel log was being spammed with errors that battery technology was not being reported (and a number of battery properties are unable to be read - specifically, those that are string based like the model, manufacturer, and technology.).

On further investigation this is caused by a bug in the i.MX I2C subsystem driver. It was fixed in kernel 6.16+ with this commit: i2c: imx: fix emulated smbus block read · torvalds/linux@a5d0b9e · GitHub

Since this is a built-in driver and difficult to change, I was able to work around it by patching sbs-battery.c (and loading it via torizon-core-builder) to use its fallback string-read function all the time.

(linux/drivers/power/supply/sbs-battery.c at 50c19e20ed2ef359cf155a39c8462b0a6351b9fa · torvalds/linux · GitHub)

Would the Toradex team consider backporting the I2C subsystem patch to the Torizon 7.x kernel? (assuming that e.g. a sufficiently new kernel/Torizon release are not on the horizon in the next few months)

Thanks!

2

Hi, I’m the Toradex AI Assistant.

I might make mistakes or occasionally get you wrong. Our support team will step in if needed.

I²C SMBUS Block Read Issue on Verdin iMX8MP

Thank you for the detailed analysis of the I²C SMBUS block read issue with smart battery systems on the Verdin iMX8MP. Your identification of the kernel bug and workaround demonstrates excellent troubleshooting skills.

Understanding the Issue

The issue you’ve encountered relates to the I²C subsystem driver in the kernel used by Torizon OS 7.x(1). As you correctly identified, this affects SMBUS block reads, which are essential for reading string-based properties from smart batteries.

Current Kernel Architecture

According to the Toradex documentation, the Verdin iMX8MP uses a downstream kernel based on the toradex_6.6-2.2.x-imx branch(2). The kernel source can be obtained using:

$ git clone -b toradex_6.6-2.2.x-imx git://git.toradex.com/linux-toradex.git
$ cd linux-toradex

(2)

Your Workaround Approach

Your solution of patching the sbs-battery.c driver and loading it via TorizonCore Builder is a valid approach for addressing this issue. The TorizonCore Builder tool supports building external kernel modules, which is documented in the available resources(3).

Kernel Module Development Options

For kernel-level modifications like this, you have several options:

  1. Build custom kernel modules using TorizonCore Builder(3)
  2. Build the complete kernel from source following the documented procedures(2)
  3. Apply patches during the build process as part of your custom image creation(2)

Regarding Backporting Requests

While I understand your request for backporting the upstream fix to Torizon 7.x, I don’t have specific information about Toradex’s kernel backporting policies or timelines in the available documentation.

Alternative Solutions

In the meantime, your current workaround using TorizonCore Builder to load a modified driver is the recommended approach. The tool is specifically designed to handle such customizations while maintaining the benefits of the Torizon platform(3).

You can also consider building a complete custom kernel with the patch applied, following the kernel building documentation(2), though this requires more maintenance effort for future updates.

Best regards, Toradex AI Assistant.

Did you like my answer? :+1: :-1:

If I answered your question, please tick the “Solution” checkbox.

For follow-up questions to me, please use @ToradexAI in your post.

3

Update: Scratch that - I see the fix was already backported in the Toradex kernel branch - I didn’t look at the actual code and only the version numbers. :frowning:

No further action required apart from us updating to a more recent build of Torizon!