camera firmware problems

[kqlnut]

I just found out that my phone has problems with the ov5640 camera firmware as reported here. The firmware is loaded, but apparently can't be started correctly which leads to the autofocus feature not working. Other than that taking pictures works. This is the output from dmesg:

Code:

[ 72.687561] ov5640 4-004c: firmware upload success
[ 72.996306] ov5640 4-004c: uploaded firmware didn't start, got to 0x7f, retrying...
[ 73.304696] ov5640 4-004c: uploaded firmware didn't start, got to 0x7f
[ 73.311504] ov5640 4-004c: ov5640_set_ctrl_focus: no autofocus firmware loaded

 
This happens every time I open Megapixels. I tried it on Manjaro Phosh unstable from eMMC and on the latest Mobian nightly from an SD card. I cannot recall it ever having worked in the past either. Apparently it works for other people though

Does anyone have more insights on this? Could this be faulty hardware which could be fixed by replacing the camera?

[dsimic]

Based on the kernel patch that implements the autofocus feature for the PinePhone's rear camera (OV5640), the kernel messages you've provided indicate that the autofocus firmware uploaded to the camera's integrated MCU failed to start executing on the MCU as expected, despite the patch attempting to query the status of the MCU multiple times in the ov5640_copy_fw_to_device() function.

It might be caused by a faulty camera module, which would be fixed by replacing the camera module.  However, you should probably contact Martijn Braam first, who is the author of the autofocus kernel patch, and report this issue.  The above-linked patch contains Martijn's contact details.

[vortex]

I get the same thing. Either it is a hardware fault we both have (e.g. faulty batch and we got cameras from the same batch) or it is a software issue.

[kqlnut]

Thank you for your replies. I figured I'll try to alter the patch first to have the camera driver wait longer for the firmware to start before giving up (right now it's 250 ms) in case it maybe just takes longer to start with some units like mine. But I have never built and replaced kernel modules, so I'll have to figure that out first when I have the time. I'll contact Martijn too though.

[dsimic]

Sounds like a plan.  Please, keep us updated.

As a suggestion, you may want to use the PKGBUILD and the associated files provided by Manjaro ARM.  Just clone the linux-pinephone repository, alter the autofocus patch, bump up the value of "pkgrel" in the PKGBUILD file to 10 or so (which will allow you to easily revert back to the stock kernel packages), and use makepkg to build the patched kernel packages.  After the build is complete, install the new packages as usual.

[kqlnut]

Sounds like a plan.  Please, keep us updated.

As a suggestion, you may want to use the PKGBUILD and the associated files provided by Manjaro ARM.  Just clone the linux-pinephone repository, alter the autofocus patch, bump up the value of "pkgrel" in the PKGBUILD file to 10 or so (which will allow you to easily revert back to the stock kernel packages), and use makepkg to build the patched kernel packages.  After the build is complete, install the new packages as usual.

Thank you for the instructions, that made everything a lot easier than I had anticipated. I changed the patch and rebuilt the package on the Pinephone itself (took about 2:15 h in case anybody wonders). I increased the time to wait for the firmware to start to 10 times as much (2.5 seconds), but still the same problem unfortunately. So maybe it is faulty hardware. I will eventually order another camera module, but it'll take a while. I will report back if I have any news.

[dsimic]

Thank you for the instructions, that made everything a lot easier than I had anticipated. I changed the patch and rebuilt the package on the Pinephone itself (took about 2:15 h in case anybody wonders). I increased the time to wait for the firmware to start to 10 times as much (2.5 seconds), but still the same problem unfortunately. So maybe it is faulty hardware. I will eventually order another camera module, but it'll take a while. I will report back if I have any news.

You're welcome and I'm glad that the instructions helped.

I'm sorry to hear that increasing the timeouts didn't help.  After having a second look at the kernel autofocus patch, which by the way contains a chunk of code that's duplicated (lines 141-156 are the same as the lines 163-175), I can confirm that it follows the steps of the autofocus firmware initialization, described on page 8 of the OV5640 Embedded Firmware User Guide.  There isn't much more that could be done from the software side, as far as I can see, but Martijn probably knows better.

What came to my mind is that the issue could be of a, so to speak, mechanical nature.  See, the driver expects the autofocus firmware to reach the S_IDLE (0x70) status, which is described as "idle state, focus is released; lens is located at the furthest position".  Another two statuses, S_FIRMWARE (0x7F, "firmware is downloaded and not run") and S_STARTUP (0x7E, "firmware is initializing"), are pretty much ignored while checking for a successful initialization of the autofocus feature, meaning that the lens has to physically move to the furthest position to declare the autofocus firmware initialization successful.  However, you got this kernel message earlier:

Code:

[ 73.304696] ov5640 4-004c: uploaded firmware didn't start, got to 0x7f

This means that the autofocus firmware initialization reached the above-described S_FIRMWARE (0x7F) state, so the issue unfortunately doesn't seem to be of a mechanical nature.  If the firmware initialization reached the S_STARTUP state instead, the root cause of the issue would have probably been a stuck lens, so tapping or knocking on the camera module, which is also known as "percussion maintenance", could probably resolve the issue.  Anyway, it might be worth giving the camera module a knock or two; I had a phone with a built-in, motorized camera lens cover that sometimes got stuck and the camera refused to work, which was a known issue that was commonly resolved by applying some light "percussion maintenance" to the camera.

By the way, isn't it awesome to own a smartphone that, from the software side, can rather easily compile the very kernel it's running?

[kqlnut]

I'm sorry to hear that increasing the timeouts didn't help.  After having a second look at the kernel autofocus patch, which by the way contains a chunk of code that's duplicated (lines 141-156 are the same as the lines 163-175), I can confirm that it follows the steps of the autofocus firmware initialization, described on page 8 of the OV5640 Embedded Firmware User Guide.  There isn't much more that could be done from the software side, as far as I can see, but Martijn probably knows better.

I looked at it again too and saw that maybe the firmware wasn't even uploaded correctly in the first place? I'm in no way experienced with this, but to my understanding it seems like the firmware is written (l. 126–129) without checking for errors. Then the autofocus registers are set, including the FW_STATUS register (0x7f – downloaded and not running). After that a system reset is done which is checked for errors, but that has nothing to do with the the autofocus firmware. If that was successful, we are informed that the firmware upload was successful. So maybe the firmware upload wasn't successful after all?
(The duplicated lines are for resetting the MCU and then retrying to start the firmware.)

What came to my mind is that the issue could be of a, so to speak, mechanical nature.  See, the driver expects the autofocus firmware to reach the S_IDLE tapping or knocking on the camera module, which is also known as "percussion maintenance", could probably resolve the issue.  Anyway, it might be worth giving the camera module a knock or two; I had a phone with a built-in, motorized camera lens cover that sometimes got stuck and the camera refused to work, which was a known issue that was commonly resolved by applying some light "percussion maintenance" to the camera.

Very interesting idea! I went Tito Puente on the camera and the firmware did in fact start successfully one time! Only one time though out of at least 10 I tried and I couldn't reproduce it. Unfortunately I was too quick to close Megapixels before I checked the dmesg output, so I couldn't try if it actually worked. So maybe that's it and something really is stuck badly in the camera. The camera always makes a clicking sound twice when starting it up and I was under the impression that this was the autofocus, so I thought it was physically working.

By the way, isn't it awesome to own a smartphone that, from the software side, can rather easily compile the very kernel it's running?

I was thinking the same thing when it was compiling. That is awesome indeed!

[wfk]

Any updates?

[dsimic]

I looked at it again too and saw that maybe the firmware wasn't even uploaded correctly in the first place? I'm in no way experienced with this, but to my understanding it seems like the firmware is written (l. 126–129) without checking for errors. Then the autofocus registers are set, including the FW_STATUS register (0x7f – downloaded and not running). After that a system reset is done which is checked for errors, but that has nothing to do with the the autofocus firmware. If that was successful, we are informed that the firmware upload was successful. So maybe the firmware upload wasn't successful after all?

You're right, the for loop that writes the firmware to the camera MCU (lines 126–129 in the kernel autofocus patch) should be checking the return value of the ov5640_write_reg() function.  Also, the code block that performs the MCU reset after completing the firmware loading (lines 132–139 in the patch) should be checking the return value of the same function.  If you have time, maybe you could add some error checking there, recompile the kernel, and check the results?

Very interesting idea! I went Tito Puente on the camera and the firmware did in fact start successfully one time! Only one time though out of at least 10 I tried and I couldn't reproduce it. Unfortunately I was too quick to close Megapixels before I checked the dmesg output, so I couldn't try if it actually worked. So maybe that's it and something really is stuck badly in the camera. The camera always makes a clicking sound twice when starting it up and I was under the impression that this was the autofocus, so I thought it was physically working.

Those are interesting results, although the rate of success doesn't seem to indicate that the root cause is stuck lens.  I also hear the clicks you've decribed; those should be the initial autofocus resets, which the camera seems to be doing on its own when powered up.  The fact that you hear those "initialization" clicks probably means that the lens isn't stuck, so let's hope that the issue is fixable in the kernel driver.