WTF is a Veo?

Can anyone explain what this cpu_type represents?  And yes, reasons I’m delving around in libstuff to follow within a few days…

Liked it? Take a second to support Graham Lee on Patreon!
This entry was posted in whatevs. Bookmark the permalink.

8 Responses to WTF is a Veo?

  1. Anonymous says:

    There are three references to “veo” in the Xserve Remote Diagnostics manual, but nothing saying what it is.

  2. Graham Lee says:

    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…

  3. Anonymous says:

    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 :-)

  4. Graham Lee says:

    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 :-)

  5. Anonymous says:

    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?

  6. Graham Lee says:

    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 ;-)

Leave a Reply

Your email address will not be published.

This site uses Akismet to reduce spam. Learn how your comment data is processed.