Misc hardware and software notes

Notes on repairing defective TiVo series 2 power supplies (the bad capacitors plague).
Series 2 power supplies often fail, I've gone through 3 of them. The symtoms are weird boot problems, temperature warnings then failure to boot, finally failure to even show the initial grey screen. Getting down to the nub of the problem wasn't too difficult, the flakey electrolytic capacitors were the culprits. On all the ones I've worked on, the capacitors had NOT exploded yet. The TiVo seems sensitive enough to the quality of the power that it stops working before the capacitors get to the exploded stage. My solution was to replace ALL of the electrolytics on the power supply. The bad ones were labeled LTEC. Note that you will have to carefully remove the white goo put on the power supply between parts that make them vibration resistant. I just carefully cut it out with a small diagonal cutters and gently pulled the chunks out with a needle nose pliers. Here is a list of the ones I replaced:

2 x 2200 @ 10 volts
1 x 470 @ 25 volts
1 x 1000 @ 16 volts
1 x 47 @ 63 volts
1 x 10 @ 50 volts
2 x 2.2 @ 50 volts
3 x 470 @ 10 volts
It was probably just the large capacity ones but since they were all LTEC I replaced them all.

Notes on using a Rev C iMac (also applies to Rev A and B and probably Rev. D) with newer versions of OSX.
The boot partition on OSX has to lie within the first 8 gigs of the start of the hard drive and the maximum hard drive size is 128 gigs. (though for some reason, while OSX only sees the first 128 gigs of the drive Linux seems to pay no attention to the 128 gig limit, more on that later). You can use a technique similar to that used by some XServe machines to get around this. What you do is have a boot helper partition, then one large partition with OSX. The easist way to do this is to install using XPostFacto. This is normally used to allow the installation of OSX onto unsupported old world boxes (prior to the iMac) but supports installation and booting using a helper disk. OSX 10.3 can be installed this way with the built in CD drive but OSX 10.4 requires a DVD drive (internal only) or the dvd copied to another hard disk. I pulled my iMac apart and temporarily replaced the standard HD cable with a PC one leaving the hard drive as master and attaching a dvd drive as slave. Next I installed OS9 creating 3 partitions, one 7 gig for OS9 (extended hfs), one 200 meg for the osxboot (extended hfs) and the rest of the space for osx (extended hfs). After installing OS9 load up and install XPostFacto4 then run it to install OSX 10.4 from the DVD specifying the osxboot partition as the helper disk and the DVD as the boot device. After going through all of the 10.4 installation, you'll get to the point where the machine wants to reboot. In my case the reboot FAILED! There seems to be a bug in XPostFacto4 that writes the Open Firmware parameters wrong for the new setup. What I do at that point is to zap pram (option apple PR while powering up the iMac) go back into os9, check the XPostFacto4 Open Firmware settings, reboot again going into Open Firmware (option apple OF) then type in the commands by hand using setenv. This works great for me. You only have to do it once unless you zap the pram again or your motherboard pram battery needs replacing. You can do a "nvram -p" command in an OSX terminal to see your Open Firmware settings. Here are mine after running XPostFacto then rebooting:

diag-file       diags
oem-banner?     false
virt-size       -1
fcode-debug?    false
output-device   screen
real-mode?      false
use-generic?    true
input-device    adb-keyboard
mouse-device    mouse
virt-base       -1
selftest-#megs  0
load-base       0x800000
boot-device     ide0/@0:7,\BootX.bootinfo
boot-args        -v rd=*ide0/@0:8
screen-#columns 100
ASVP  0111??003<00%00
boot-command    mac-boot
real-base       -1
pci-probe-mask  -1
boot-file       -h
auto-boot?      true
diag-switch?    false
screen-#rows    40
diag-device     floppy
little-endian?  false
default-mac-address?    false
use-nvramrc?    false
real-size       -1
oem-logo?       false

If you look at the settings above and compare them to the Partitions list just below, you see that boot-device describes the helper partition and boot-args describes the root partition. XPostFacto automatically sees any kernel changes and recopies them to the helper partition when you reboot (or after one boot if you've done a software update that required a reboot). For some unknown reason XpostFacto doesn't messup the Open Firmware commands when you use it to reboot from OSX, EXCEPT for the input device! You can use the following command from terminal in OSX to fix that:

sudo nvram input-device="keyboard"

My partition map follows:

dev:/var/log root# hdiutil pmap /dev/rdisk0
Partition List
## Dev_______ Type_______________ Name_____________ Start___ Size____ End_____
 0 disk0s1    Apple_partition_map Apple                    1       63       63
 1 disk0s2    Apple_Driver_ATA    Macintosh               64       54      117
  disk0s3    Apple_Driver_ATA    Macintosh              118       74      191
 3 disk0s4    Apple_Driver_IOKit  Macintosh              192      512      703
 4 disk0s5    Apple_Patches       Patch Partition        704      512     1215
 5 disk0s6    Apple_HFS           untitled              1216 15769600 15770815
 6 disk0s7    Apple_HFS           untitled 2        15770816   409600 16180415
 7 disk0s8    Apple_HFS           untitled 3        16180416 252255029 268435444
 8            Apple_Free          Extra             268435445       10 268435454
    - ... extended entry
    + ... converted entry

Type 1 partition map detected.
Block0.blockSize 0x0200
NativeBlockSize  0x0200

(-options xsSgcvk)

If you run OSX it seems that the system limits the hard drive to 128G. I have however successfully run larger drives in linux. Here is the partition table from another rev C imac with a 160G drive. I copied a bunch of files to that drive over the 128G limit and ran a filesystem check on that partition to make sure linux was actually working properly, not just thinking (incorrectly) that it could work. This means the base hardware supports the larger drive size. This is a rather complex partition table, the drive triple boots OS9, OSX and Linux. hda13 is an xfs partition that spans across the 128G "barrier".

root@imac:~ # fdisk -l
        #                    type name                  length   base      ( size )  system
/dev/hda1     Apple_partition_map Apple                     63 @ 1         ( 31.5k)  Partition map
/dev/hda2        Apple_Driver_ATA Macintosh                 54 @ 64        ( 27.0k)  Unknown
/dev/hda3        Apple_Driver_ATA Macintosh                 74 @ 118       ( 37.0k)  Unknown
/dev/hda4      Apple_Driver_IOKit Macintosh                512 @ 192       (256.0k)  Unknown
/dev/hda5           Apple_Patches Patch Partition          512 @ 704       (256.0k)  Unknown
/dev/hda6               Apple_HFS untitled            15400000 @ 1216      (  7.3G)  HFS
/dev/hda7         Apple_Bootstrap bootstrap              16384 @ 15401216  (  8.0M)  NewWorld bootblock
/dev/hda8            Apple_Loader SecondaryLoader         1024 @ 15417600  (512.0k)  Unknown
/dev/hda9               Apple_HFS untitled            16366592 @ 15418624  (  7.8G)  HFS
/dev/hda10              Apple_HFS Macintosh           37279622 @ 31785216  ( 17.8G)  HFS
/dev/hda11        Apple_UNIX_SVR2 swap                 1953126 @ 69064838  (953.7M)  Linux swap
/dev/hda12        Apple_UNIX_SVR2 root                19051876 @ 71017964  (  9.1G)  Linux native
/dev/hda13        Apple_UNIX_SVR2 untitled           230089545 @ 90069840  (109.7G)  Linux native
/dev/hda14             Apple_Free Extra                  13671 @ 320159385 (  6.7M)  Free space

Block size=512, Number of Blocks=320173056
DeviceType=0x0, DeviceId=0x0
1: @ 64 for 21, type=0x701
2: @ 118 for 34, type=0xf8ff

last modified Fri, Jan 29, 2016