SBORPS Random Fact 02
All clocks used by the PSP hardware are derived from a single clock generator IC. It uses a single 27MHz input crystal (there are 2 other crystals, a 4MHz & a 32.768KHz, but is purely for the syscon chip) and can output the following frequencies:
- 37MHz (Spread Spectrum Configurable, used for CPU/PLL freq)
- 48MHz (used for USB freq)
- 27MHz reference (used for video clock on slim)
- 22.5792MHz (used for Lepton clock)
- 22.5792/24.576MHz selectable (used for Audio Codec IC, for audio freq 44.1KHz/48KHz)
The clockgen IC is accessible on the I2C bus on slave address 0xD2. It has 3 registers:
Reg0: Vendor ID/Revision Code Register
Reg1: Output Control Register
Reg2: Spread Spectrum Control Register
Special Note:
Why TA-082/086 motherboards ‘bricked’ on 1.50 was because the clock generator IC was from a different manufacturer on those boards and so had a different Vendor ID/Revision Code than on TA-079/081 boards. The 1.50 IPL doesnt recognise the new Vendor ID/Revision Code so it freezes (which caused the ‘brick’).
The Spread Spectrum Control register is configured depending on the revision, the 1.50 IPL only recognises revisions 0×4 and 0×8 of that IC, the new IC of TA-082 boards had a revision of 0xF. Interestingly, revision 0xF IC’s are supported starting from 2.00 so in all likelyhood TA-082/086 boards could be downgraded to as low as 2.00 without brick. The TA-082/086 boards do NOT ‘blacklist’ firmwares lower than 2.50 like some people have stated. It was NOT designed to ‘block out’ the 1.50 firmware.
So how come the TA-082 downgraders work then? The configuration of the clock generator IC is based on paramaters stored in idstorage key5 (header is “Clkg” – short for Clockgen). If key5 is corrupt the configuration of the clock generator is simple skipped altogether (only the header needs to be modified for the key to appear invalid – ie. if the header is not “Clkg” it is considered corrupt).
So corrupt key5 -> clockgen config is skipped -> 1.50 IPL continues to run.
EDIT: added some extra info on 1.50 downgrader
February 22nd, 2008 at 2:56 am
Is the battery mc (IIRC the spec of the serial lead coming off the controller from the battery would fall in line with I2C) not on the I2C bus as well, with syscon obscuring/simplifying it? meh, syscon probably doles out I2C anyway.
February 22nd, 2008 at 10:30 am
Do you know which micro the battery uses? The comm line is a 1-wire async serial, so it’s not I2C.
Syscon probably has I2C (as a master to other devices) but it wont be on the same bus as the CPU I2C bus, the only I2C slave devices the CPU controls is the clock generator (addr 0xD2), the audio codec (addr 0×34), and the video out IC on slim (addr 0×42).
February 23rd, 2008 at 10:33 am
I figured it might be a bit much to ask that it all be easily usable on a single bus
To the best of my knowledge the batteries are using a (or possibly, since the logo is MIA, a clone of the) NEC 78K0/KB1+ (8-Bit Single-Chip Microcontrollers) – the operation of the pins is configurable, I2C (among others) is listed as one of the available options on the 780102H, some pins (as well as package specs) line up to well to the datasheets, and the application seems pretty accurate for what it was made for.
February 23rd, 2008 at 4:44 pm
Really really???? It’s a 78K core??
Because…well…that’s *very* interesting…:p
February 24th, 2008 at 3:26 am
Really really… the datasheet’s plausible uses for the pinout matches up very very well. The way they mess with the silkscreens and occasionally use clones in mass runs though, I have no 100% certainty aside from the fact in over 2hrs searching it was the only thing close I could find.