Solving Issues With the Olive O4HD Display
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.
[ 1070.160000] zusbfb_blank-(1183):: Entering blank(4)
[ 1070.700000] zusbReceive-(197):: A request received a urb Status->-71 bad response->1929447251 function->111
[ 1071.710000] mmpSetPowerMode-(1045):: Retrying (0)
[ 1072.720000] mmpSetPowerMode-(1045):: Retrying (1)
[ 1073.730000] mmpSetPowerMode-(1045):: Retrying (2)
[ 1074.740000] mmpSetPowerMode-(1045):: Retrying (3)
[ 1075.750000] mmpSetPowerMode-(1045):: Retrying (4)
[ 1075.750000] mmpSetPowerMode-(1049):: Failed to setpowermode
[ 1075.750000] zusbfb_blank-(1214):: Failed to turn off backlight.. Retries exhaustedUnfortunately 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.
iVendor 0 iProduct 0
iVendor 5E3 iProduct 608
iVendor 1DBA iProduct 220
find smidia device iVendor 1DBA iProduct 220
zusbInitializeFB....
usb_submit_ur11 failed for 1st hdr urb ctxt retVal(-1)Failed to transmit headerusb_submit_ur11 failed for 1st hdr urb ctxt retVal(-1)Failed
to transmit headerlcdaBase = 0
lcdbBase = 0
usb_submit_ur11 failed for 1st hdr urb ctxt retVal(-1)Failed to transmit headerusb_submit_ur11 failed for 1st hdr urb ctxt retVal(-1)Failed
to transmit header
Reset IDE: OKI 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.
~ # cd /zapp/zbase/smedia_upgrade
/zapp/zbase/smedia_upgrade # ./pre_upgrade.sh
[42949478.270000] zusb_release-(220):: Entering usbCtxt->c7c42cc0
[42949491.110000] hub 1-1:1.0: transfer --> -71
[42949491.110000] hub 1-1:1.0: (hub_irq) In the middle of reset, don't submit any more requests to hub
[42949491.120000] usb 1-1: unlink qh256-0001/ffc24100 start 255 [7/0 us]
[42949491.130000] usb 1-1: link qh256-0001/ffc24100 start 255 [7/0 us]
[42949491.140000] usb 1-1: unlink qh256-0001/ffc24100 start 255 [7/0 us]
[42949491.140000] hub 1-1:1.0: (hub_reset) Performing reset device on hub (c06822c0)
...
filesize = 393960 , checksum = 0x0323DA03
Issuing NorInitialize
0
0 , 349613 us
1
1 , 349629 us
...
96
96 , 349617 us
Issuing NorProgramming, retry = 0
wait 30 seconds ... DO NOT turn off power or reset
30
Issuing NorGetStatus,retry = 0
Issuing NorTerminate, retry = 0
[42949582.600000] zusb_release-(220):: Entering usbCtxt->c7c42cc0
[42949583.650000] Entering hub_events
[42949583.650000] hub 1-1:1.0: state 5 ports 4 chg 0000 evt 0010
[42949583.660000] hub 1-1:1.0: (hub_port_connect_change) port 4, status 1100, change 0001, 12 Mb/s
[42949583.670000] usb 1-1.4: USB disconnect, address 6
...
[42949585.950000] mmpM2dGetScreenSurface-(332):: Screen Surface A c7c42c80 ea308
[42949586.190000] mmpM2dSetVisibleLCD-(675):: SetVisible to LCDA
[42949586.190000] hub 1-1:1.0: state 5 ports 4 chg 0000 evt 0010
[42949586.200000] Exiting hub_events
[42949589.080000] zusb_release-(220):: Entering usbCtxt->c7c42cc0
510+0 records in
510+0 records out
/zapp/zbase/smedia_upgrade # 2014-11-19 23:04:17: (log.c.135) server stopped
killall: mt-daapd: no process killed
killall: sshd: no process killed
killall: syncawayd: no process killed
killall: mt-daapd: no process killed
killall: ntpd: no process killed
killall: postmaster: no process killed
Sync hardware time to system time (utc) : Wed Nov 19 23:04:26 GMT 2014
The system is going down NOW !!
Sending SIGTERM to all processes.
Sending SIGKILL[42949614.610000] usbcore: khubd exiting
Please stand by while rebooting the system.
[42949617.660000] zusbfb_notify_sys-(1414):: Received SYS_DOWN/SYS_HALT
[42949617.660000] Restarting system.
[42949617.670000] Reseting !!
...
USB Display found
USB Display(smedia) detected, installing driver...
[42949380.670000] zusb_probe-(302):: usbCtxt->c7c42cc0, Device->c069ac00, Interface->c0655b20 Minor->0 endpoints->2 numalt->1
[42949380.680000] zusb_probe-(327):: Bulk In EP->1 Bulk Out EP->2
[42949380.690000] zusbInitializeFB-(1755):: Entering fbCtxt (00000000) switchingActive (0)
[42949380.830000] SMEDIA Version = 3.0
[42949380.830000] fbopt = 1, framerate = 7 surfaceChecksum = 0 enableMarker = 1
[42949380.840000] hostdrawRegions = 2 regionSize = 130560, regionHeight = 136
[42949380.850000] zusbInitializeFB-(1907):: primary and secondary frame buffers allocated->c78c0000:c7900000 order->6 size->0x3fc00
[42949380.990000] mmpM2dGetScreenSurface-(332):: Screen Surface A c7c42c80 ea308
[42949381.230000] mmpM2dSetVisibleLCD-(675):: SetVisible to LCDA
[42949381.230000] KT debug lcdWidth= 480 , bulk_size:8
...
BusyBox v1.01 (2006.06.29-04:09+0000) Built-in shell (ash)
Enter 'help' for a list of built-in commands.
/bin/sh: can't access tty; job control turned off
~ # I have now had many trouble-free weeks.