20

I'm trying to identify the operating system on a Thermo-CRS C500 robot arm controller. From the specifications I know it runs on a 100 MHz 486 processor, and has 4 MB RAM and 2MB of flash/NVRAM combination for filesystem.

All the identifying strings in the system only refer CROS -- CRS Robot Operating System -- v 3.1.1249. It may be that this is a completely custom kernel, but it might also be based on some kind of BSD or other UNIX-like system.

The system shell has a quite unix-like environment. Most of the system binaries, such as /bin/cp and others are implemented in some kind of bytecode. The bytecode interpreter resides in /sbin/r3interp, which file indentifies as FreeBSD/i386 compact demand paged executable.

The kernel binary contains some strings that could help identification:

  • Caught wild IRQ 0
  • double fault exception (very bad) [e=%08x]
  • invalid TSS exception [e=%08x]
  • Cur_Proc->pr_vfsd.vf_vp == 0
  • sp->owner == Cur_Proc->proc_id

In particular the x86 exception names exist in most kernels, but not in that form. I have already checked late 1990s versions of FreeBSD, 386BSD, Linux 1.x, Minix 1 and 2, Xenix 386 and NetBSD, but haven't found a match. For more detailed analysis, binaries are here and boot messages here.

Can someone figure out some obscure Unix version that might be the base of this customized system?

jpa
  • 1,696
  • 7
  • 17
  • What about an in house product? – UncleBod Jun 14 '20 at 11:26
  • 4
    Even an in house system is going to start from something with this file system. – Mark Williams Jun 14 '20 at 11:44
  • Have you tried to identify the manufacturer? They might be willing to tell you. – UncleBod Jun 14 '20 at 12:22
  • 1
    @UncleBod I haven't tried contacting them for this, but some other people did about other information about the system - it seems they don't have anyone who could answer, as the system hasn't been manufactured since ~2003. – jpa Jun 14 '20 at 13:43
  • What happens if you use readelf on r3interp? – John Dallman Jun 14 '20 at 14:51
  • @JohnDallman Error: Not an ELF file - it has the wrong magic bytes at the start. I'm not sure what kind of binary format it actually is. – jpa Jun 14 '20 at 15:18
  • @jpa: Plausibly a.out. – John Dallman Jun 14 '20 at 17:52
  • @JohnDallman Yeah, unfortunately modern multiarch-objdump does not recognize it. Radare2 does, but it's of course statically compiled and stripped of symbols, so not much to see there. I was hoping if it was some well known target, the syscalls could be figured out. But I guess I'll keep banging at RAPL-3 - the system has a compiler for it. – jpa Jun 14 '20 at 17:59

1 Answers1

18

Here's a manual for CROS and one for the C500C robot controller. It seems clear that the bytecode files are compiled from the RAPL-3 programming language (no filename extension for binaries, .r3 for source files, .v3 for "variables files". There's a manual for the language here and for the development tools, which run on Windows, here. The manual for updating CROS on the controller is here which makes it clear that CROS is updated by re-writing the OS image on the controller, then rebuilding the filesystem on the controller.

I can't find anything in any of these manuals that indicates that CROS is based on any other OS. Given the scale of the software provided for it, it seems plausible that it was purpose-written for the job. Re-using a BSD file format would save some wheel-reinvention, but it could also be a coincidence of magic numbers. The boot-up messages don't say anything about the Regents of the University of California, which is a requirement with BSD-licensed code.

John Dallman
  • 13,177
  • 3
  • 46
  • 58
  • 2
    Yeah, I guess you are right. Nowadays it would be weird for any company to spend so much time reinventing the basic operating system, but things were different back in 1990s. And after all they did make up a custom programming language. – jpa Jun 14 '20 at 15:20
  • 7
    I think we often overestimate the effort it takes to design a programming language, or implement a compiler or operating system. Yes, implementing an operating system that can reliably run on millions of possible combinations of CPUs, busses, graphics cards, storage controllers, network cards, can scale from watches to 10000 CPU supercomputers, can support batch, interactive, transactional, and realtime workloads, support I/O-bound and CPU-bound workloads, steady and highly volatile workloads, and be easy to use for novices while being powerful for experts is hard. But this is not such an OS. – Jörg W Mittag Jun 14 '20 at 19:59
  • 5
    … this OS has 1 well-defined hardware platform, 1 well-defined workload, and 0 users. – Jörg W Mittag Jun 14 '20 at 20:00
  • 2
    @jpa Not at all. For robotics and industrial equipment it is in fact very common to write the entire operating system from scratch. The only reason you'd use an existing operating system is if you need TCP/IP networking and can't find a good library or save files on standard filesystems like NTFS or EXT3 and can't find a good libraryor need a GUI and can't find a good library because they require writing complicated drivers . If you're doing none of the above it's easier to manage your processes directly by using timer interrupts in your own code – slebetman Jun 15 '20 at 06:30
  • @slebetman Yeah, for very low-level stuff. But this seems to have a lot of the standard POSIX APIs or at least similar available, and the realtime stuff is dedicated to another processor running some kind of different system. But I guess they've imitated BSD just for familiarity. – jpa Jun 15 '20 at 07:10
  • @jpa When I worked on my first OS, I used file formats that could be easily edited in development (MS-DOS at the time). This included compatible (bare) executables, for a while. But the r3interp match is more likely accidental (it doesn't match the actual file format, as far as I can tell). Having rooted file system wasn't specific to Unix either. Rooted FSs were common with hard-drives, drive letters are much more convenient for floppy-based OSes, like the original MS-DOS. There's a 486 CPU in the controller, so x86 exceptions are to be expected. Probably OS from ~scratch. – Luaan Jun 15 '20 at 09:40
  • 2
    Way back when, working on an embedded system, I wrote an OS in 8086 assembly. It handled radio communications using a homegrown protocol, dynamic memory management, digital and analog I/O, and it had a bytecode interpter. I also wrote the compiler, in C, that turned a DSL into bytecodes to run on the embedded system. It wasn't as big a task as a modern OS because the requirements were very specific. I only had to support just what the system needed, no more, no less. – Wayne Conrad Jun 15 '20 at 14:34
  • 1
    Once upon a time, there was a Swedish company called DIAB, who got tired of writing custom OSes for industrial control and decided that the next thing would be a general OS, for industrial control. Starting from a System III source-code license, they wrote D-NIX, a unix-like operating system with real-time scheduling extensions, as well as asymmetric multi-processor support. These days, the only remnant part is their internal compiler division, owned by (IIRC) Wind River Systems. – Vatine Jun 15 '20 at 14:43