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

Environment Variables

The ARC/ARCS maintains an environment, which is a list of variable names and corresponding values (the values are actually text strings). These environment variables contain information that the command monitor either uses itself or passes to booted programs. The system stores some environment variables (those that are important and unlikely to change frequently) in NVRAM.

Variable

Description

ConsoleIn/ConsoleOut

StdIn/StdOut

OSLoadPartition

The disk partition where the operating system kernel is located.

OSLoader

The operating system loading program.

SystemPartition

The disk partition where the operating system loading program is found.

OSLoadFilename

The filename of the operating system kernel.

OSLoadOptions

An additional options to the boot command.

AutoLoad

This variable specifies whether the operating system will boot automatically. Can be Yes or No.

ARC vs ARCS

Endianess

For the ease of Microsoft's Windows NT effort the ARC standard defines the byte order to be little endian only. SGI systems where ARC is called ARCS violate that by being big endian.

Boot-PROM

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(8) is a SGI Volume Header. This names are used as value for ARCS environment variables, i.e. for SystemPartition.

On a 64-bit ARC systems all SPB pointers are 64-bit. See an ARCLoad sources for more details.

Firmware call vector

Firmware functions are called indirectly through call vector table. Arguments to functions are placed in registers a0 to a3. Return values are placed in register v0.

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.

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.

Milo/Pandora

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.

Arcboot

Arcboot is a first stage bootloader that is able to load ELF32 and ELF64 kernel files from both ext2 and ext3 filesystems.

Network Booting

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.

TFTP Problems

Machine doesn't download the kernel when I try to netboot

This problem has been observed with the ARC firmware of SNI RM_200 and SGI IP22.

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 TFTP 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

tftp-hpa

The latest version of the tftp-hpa tftp daemon has a workaround for the problems described in the previous two sections. The tftp-hpa git repository can be cloned from http://www.kernel.org/pub/scm/network/tftp/tftp-hpa.git. The latest version disables PMTU discovery by default; the port range can be restricted with the -R from:to option. Note this options is hugely preferable over above workarounds which seriously limit the function of the entire IP stack for the sole purpose of getting a machine booted.

This is new experimental code; please send test reports to syslinux@zytor.com and linux-mips@linux-mips.org.

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.