- 1 The ARC Standard
- 2 ARC Path Naming Convention
- 3 ARC vs ARCS
- 4 API
- 5 32-bit vs. 64-bit
- 6 ECOFF and ELF support
- 7 Milo/Pandora
- 8 Arcdiag
- 9 Network Booting
The ARC Standard
was born in the early 90s as part of the Advanced Computing Environment (ACE) initiative. It standardized certain hardware features and the ARC firmware environment. What all ARC implementations have in common is their strict non-compliance to the ARC standard, so the ARC Standard document should be taken with a shovel of salt.
ARC Path Naming Convention
ARC Path Naming Convention is defined in the MS Knowledge Base article Q102873.
ARC vs ARCS
ARCS and ARC differs in some constatns:
SCSI Host ID
On the most SGI's computers the default SCSI Host ID is 0 instead of 7.
See SGI hardware Frequently Asked Questions (FAQ), section 52.
ARC systems uses MS-DOS MBR partition layout for hard drives and conventional ISO-9660 for CD-ROMs.
scsi(0)disk(0)rdisk(0)partition(0) on ARC is used to access a whole raw disk (like /dev/sda).
On a SGI's ARCS systems all disks (even CD) must have a IRIX volume header and partitions. A typical IRIX bootable volume consists of the following partitions:
- Partition 0 - Root Filesystem partition.
- Partition 1 - Swap partition.
- Partition 7 - Volume Body partition.
- Partition 8 - Volume Header partition.
- Partition 10 - Whole Disk partition.
The Volume Header partition must start at the first sector on the disk. It contains the disk label in the first sector, and a rudimentary filesystem (readable by the PROM Monitor) in the rest of the partition.
To boot a file on ARC BIOS system use an "ARC Path Naming Convention", i.e.
multi()disk()fdisk()arcdiag - for floppy,
scsi()cdrom(6)fdisk()\os\nt\osloader.exe - for CD-ROM and
scsi(0)disk(0)rdisk(0)partition(1)\boot\vmlinux - for 1'st hard drive partition.
SGI's big endian ARCS can read SGI-disklabelled disks only. The
scsi(0)....partition(0) is a valid name for the first partition and
scsi(0)....partition(7) is a SGI Volume Header.
SGI BOOT PROM uses own device naming scheme. The general format is:
<driver name> (<controller id>, <device id>, <partition>)
ARC BIOS provides a call vector table for the ARC BIOS services.
N Offset Name 00 0x00 Load 01 0x04 Invoke 02 0x08 Execute 03 0x0c Halt 04 0x10 PowerDown 05 0x14 Restart 06 0x18 Reboot 07 0x1c EnterInteractiveMode 08 0x20 ReturnFromMain 09 0x24 GetPeer 10 0x28 GetChild 11 0x2c GetParent 12 0x30 GetConfigurationData 13 0x34 AddChild 14 0x38 DeleteComponent 15 0x3c GetComponent 16 0x40 SaveConfiguration 17 0x44 GetSystemId 18 0x48 GetMemoryDescriptor 19 0x4c Signal 20 0x50 GetTime 21 0x54 GetRelativeTime 22 0x58 GetDirectoryEntry 23 0x5c Open 24 0x60 Close 25 0x64 Read 26 0x68 GetReadStatus 27 0x6c Write 28 0x70 Seek 29 0x74 Mount 30 0x78 GetEnvironmentVariable 31 0x7c SetEnvironmentVariable 32 0x80 GetFileInformation 33 0x84 SetFileInformation 34 0x88 FlushAllCaches 35 0x8c TestUnicodeCharacter 36 0x90 GetDisplayStatus
Note, there is no Unlink or Erase call.
32-bit vs. 64-bit
The ARC standard understands itself as an environment for a 32-bit operating system. With the R4000 and DEC Alpha already being around back then a short sighted decission but good enough for another few years on small to medium sized systems.
As the result most MIPS ARC firmware implementations are 32-bit but a few more recent ones are 64-bit only; the exact way this was done was never published anywhere. The ARC firmware on Power Indigo 2, Indigo 2 R10000, Origin, Onyx 2, Octane systems is known to be 64-bit.
ECOFF and ELF support
The ARC standard mandates ECOFF support only. While appropriate for the UNIX flavours of the time which often still based on ECOFF and convenient for Windows NT which is using PECOFF, an variant of ECOFF with an MSDOS .exe header added it wasn't appropriate for any modern flavor of UNIX which usually are based on the ELF binary format. Depending on the age and operating systems offered by a particular vendor many ARC firmware variants only support ECOFF.
Booting the kernel fails with PROM error messages
>> boot bootp()/vmlinux 73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960 Setting $netaddres to 192.168.1.5 (from server deadmoon) Obtaining /vmlinux from server deadmoon Cannot load bootp()/vmlinux Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.
This problem has been observed with Indys and with RM_200. The elf2ecoff utility which is part of the kernel source allows conversion of an ELF kernel binary into a bootable ECOFF binary as the bootfile. There is also the arcboot utility which is shipping with recent Indy distributions and which as first stage bootloader is able to boot an ELF kernel of an ext2 or ext3 filesystem. Usually arcboot is the preferable solution.
In the early days of Linux/MIPS Milo was the bootloader for little endian ARC systems. It's considered obsolete and there are no systems that rely on it.
Pandora is a simple monitor and debugger included with Milo.
The arcdiag diagnostic utility is an example of the ARC MIPS standalone application.
- arcdiag sourcecode.
- arcdiag binary for the little endian ARC systems.
- arcdiag.ip22 binary for the big endian 32-bit SGI ARCS systems.
The ARC Standard mandates network booting of an operating system via BOOTP/TFTP or alternatively DCL/RIPL. Most implementations comply to that with a varying degree of buggyness; the exception is the Olivetti M700-10 where network booting is not supported at all.
Machine doesn't download the kernel when I try to netboot
The boot client is replying to the BOOTP packets (may be verified using a packet sniffer like tcpdump or ethereal), but doesn't download the kernel from your BOOTP server. This happens if your boot server is running a kernel of the 2.3 series or higher. The problem may be circumvented by doing an
echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
as root on the boot server. Alternatively you can also add this setting to /etc/sysctl.conf.
The kernel download from the TFTP server stops and times out
This may happen if the TFTP server is using a local port number of 32768 or higher which usually happens if the TFTP server is running Linux 2.3 or higher. This problem may be circumvented by doing a
echo 4096 32767 > /proc/sys/net/ipv4/ip_local_port_range
Bug in DHCP version 2
When using DHCP version 2 you might see the following problem: Your machines receives it's BOOTP reply 3 times but refuses to start TFTP. You can fix this by doing a "unsetenv netaddr" in the PROM command monitor before you boot your system. DHCP version 3 fixes this problem.