rumble wrote:I see what you mean, but I still don't believe that it would be so difficult. Setting up such state isn't magical (assuming there are docs for the CPU), it's just tedious.
MIPS isn't the worst of CPUs thankfully, but cache code is quite intricate stuff at times (I've written some). Bugs can be very tough to pinpoint and track down. Of course it mainly depends on how ambitious people may get trying to shoehorn in new CPUs with specs that vary a lot from those originally supported in O2 + IRIX.
And sometimes it does involve magic
Look in Linux from a few years ago and you might find a comment warning people "not to even breathe" on the cache initialisation code (because it was so hard to get right).
rumble wrote:Heck, this topic is covered for the R3k in about 20 pages in The MIPS Programmer's Handbook.
Things evolved a little since the R3k
I dont have any R3k book anymore, but I think it had physical indexing and tagging, direct mapping and was write through, which was about as simple as cache hardware gets. The RM7k series supports a split onboard L1 cache, joint onboard L2 cache, and off chip L3 cache.
My point is simply that the IRIX kernel is very unlikely to support this new core unmodified and that this could well prove a more substantial task than getting around the PROM limitation. Though who knows? Perhaps we'd only need to patch up the Processor ID check somewhere if the cpu is binary compatible with some already existing cache/tlb/etc configuration. Plus, symmon makes debugging much easier.
Yes. As long as things are kept similar to existing models, then it could be doable. That is probably why the 600MHz model worked so well. But AFAIK the faster CPU's Joe tried were supposed to be binary compatible as well, yet they didn't work.