After replacing the hard drive in my Olive O4HD I was still experiencing intermittent reliability issues. Occasionally the system would appear to freeze or not resume after going to sleep. I decided it would be worthwhile to restore the operating system, despite the warnings I had read about this being a bad idea. I backed up the flash to ensure I could restore that if something went wrong. Unfortunately I was unable to enter USB recovery mode as the system would hang.
I decided to gather together all of the symptoms in order to figure out what the problem might be.
Initially the display would be responsive, but it would lock up after some time. The player would continue to function over the web interface.
It was not possible to enter USB restore mode. The player would hang at the boot up screen.
Occasionally a boot would fail, leaving the system displaying the boot screen until it was manually power cycled.
Occasionally the top half of the display would lock up, leaving the bottom half functional.
Occasionally the system would not wake when the power button was pressed.
While the player was powered up I logged in via the SSH backdoor the manufacturer embedded in order to assess the situation. After the player interface froze I used dmesg to dump the kernel message buffer. The following kernel messages occur when the player’s display becomes unresponsive.
Unfortunately this was not terribly revealing. However, I did now know there was some issue communicating with the display. Given the context clues zusbfb and urb I presumed it was an issue communicating over USB.
More information was needed before I could make a decision. Using the the internal serial port I observed what happened when the player tried to enter USB recovery mode.
I was now on to something. Again, there was a failure to communicate with a device over USB; more importantly, a failure to communicate with the SMedia (misspelled as smidia) chipset. This chip drives the front LCD and very well could be responsible for the observed problems.
The chain of hardware between the CPU, SMedia chip, and the LCD screen all looked good. There was good continuity between the components and it didn’t appear as though any magic smoke had been released. I decided to dig into the upgrade process to see if there were any clues. It turns out there is indeed a step in the upgrade which flashed firmware to the SMedia chip.
There were two possibilities. In one, the SMedia chip is on its way out and attempting to flash the firmware to it again wouldn’t do any more harm. In another, the SMedia chip is running old or bad firmware and flashing the latest firmware would fix the display. Given this, I decided it was safe enough to proceed.
One key hint, which I didn’t understand at the time, was the firmware version reported 0.0 while the OS version reported 4.3.2. During the 4.3.2 upgrade the “firmware” is expected to be upgraded to version 3.0. I initially suspected that “firmware” referred to the bootstrap software (uboot) or kernel revision, but now I understand it refers to the firmware running on the SMedia chip.
I provide no warranty for the following. Everything is done at your own risk. You must know what you’re doing and the associated risks before attempting to flash the SMedia chip.
As I couldn’t run the upgrade process normally via the USB recovery mode I decided just to manually re-run the SMedia upgrade script. After reading over the source it seemed safe enough. I used the serial console to access the root shell and ran /zapp/zbase/smedia_upgrade/pre-upgrade.sh to perform the upgrade.
NOTE: While the process is running do not remove power from the player. Once the upgrade is complete the player will reboot and return to normal operation.