Can anyone explain what this cpu_type represents? And yes, reasons I’m delving around in libstuff to follow within a few days…
APPropriate Behaviour
The book about all the things software writers do that aren't writing software.
FSF
Can anyone explain what this cpu_type represents? And yes, reasons I’m delving around in libstuff to follow within a few days…
The book about all the things software writers do that aren't writing software.
There are three references to “veo” in the Xserve Remote Diagnostics manual, but nothing saying what it is.
Thanks Chris. Raises more questions than it answers, doesn’t it? What’s a vsp in this context. a virtual single processor? A virtual software processor? A vector signal processor? In any case, why would it require its own Mach-O binaries in an Xserve?
I’m entertaining two other notions: [i]it’s the chip in the Xserve RAID; [ii]it’s some CPU that NeXT-or-OSF-or-CMU added, or at least provisionally added, support for but never used back in the day. [iii]both ;-). However, the files in the Xserve RAID firmware are:
leegion:/tmp admin$ file raid-controller/updateROM.bin
raid-controller/updateROM.bin: VISX image file
leegion:/tmp admin$ file coprocessor/updateROM.bin
coprocessor/updateROM.bin: Macintosh Application (data): PLE-FIRMWARE
Curiouser and more curious…
In cctools/libmacho/arch.c we can see that it is a big-endian CPU.
In cctools/libstuff/notes we can see that it was added (maybe) in cctools-439, which maps to between 10.2.6 and 10.2.7. What got released around then?
There’s also a vendor called Veo that sells USB webcams. When did iSight get introduced?
Why would it need a CPU??
(Yay opengrok :-)
In fact, look at other source such as cctools/libstuff/reloc.c and we see that it has the same relocation type, the same stack address and direction (OK, that’s almost a given) as the PPC; I’d go as far as to say that this is a Power of some variety. Now we know that Powers are used a lot in embedded systems (there’s about a 50% chance that your car’s fuel injection system runs Power, otherwise it’s a SPARC) so it’s possible that it’s for some appliance. I don’t (and I suspect you don’t) fancy the iSight for that; yes it’s got an embedded microcontroller but it won’t need the complexity of Mach OS.
You’re right about the timeline, I hadn’t spotted that. According to Eric Levenez that puts us in May-August 2003. If I said that the Xserve RAID was debuted in Feb 2003, would you believe that CPU support for it didn’t get into the open source Mach OS until August? I would, but then I’m biased…I’ve got nothing beyond circumstantial evidence for any of this :-)
If it is a PPC variant, wouldn’t it be listed as a CPU_SUBTYPE_POWERPC_foo?
I’ve never seen an Xserve RAID – does it run a sawn off version of OS X or something?
Only if it were truly capable of running all of the code that all of the PPCs can. But what if it hasn’t got the floating-point capabilities of e.g. a 601? Why would you need an FPU in a network switch or a RAID controller? What if it hasn’t got a virtual memory space? If it’s got 16-bit registers? If it’s only got two GP registers? What if it’s a type of Power, but not of PowerPC? It might be useful in those situations to make it a new CPU_TYPE, rather than potentially have a break in binary compatibility.
As for what the RAID runs, I don’t know which is why I’m speculating ;-). I can imagine that it’s got a non-trivial firmware though, especially with two processors per controller. To the end user, the RAID is a black-box, so you don’t get to find out what it’s doing. Unsurprisingly I’ve never taken the one at work apart, either ;-)
It could!
It could!