Difference between revisions of "ARC"

From LinuxMIPS
Jump to: navigation, search
(Load64)
m (SGI Category)
 
(24 intermediate revisions by 5 users not shown)
Line 1: Line 1:
 
== The ARC Standard ==
 
== 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 [ftp://ftp.linux-mips.org/pub/linux/mips/doc/ARC/riscspec.pdf ARC Standard document] should be taken with a shovel of salt.
+
was born in the early 90s as part of the [[Wikipedia:Advanced_Computing_Environment | 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 [ftp://ftp.linux-mips.org/pub/linux/mips/doc/ARC/riscspec.pdf ARC Standard document] should be taken with a shovel of salt.
  
 
== ARC Path Naming Convention ==
 
== ARC Path Naming Convention ==
  
 
ARC Path Naming Convention is defined in the MS Knowledge Base article [http://support.microsoft.com/default.aspx?scid=kb;en-us;q102873 Q102873].
 
ARC Path Naming Convention is defined in the MS Knowledge Base article [http://support.microsoft.com/default.aspx?scid=kb;en-us;q102873 Q102873].
 +
 +
== 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.
 +
 +
{| {{PrettyTable}}
 +
!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 ==
 
== ARC vs ARCS ==
Line 11: Line 41:
  
 
For the ease of [[Wikipedia:Microsoft|Microsoft]]'s [[Wikipedia:Microsoft_Windows_NT|Windows NT]] effort the '''ARC''' standard defines the byte order to be [[Endianess|little endian]] only.  [[Wikipedia:Silicon_Graphics|SGI]] systems where ARC is called '''ARCS''' violate that by being big endian.
 
For the ease of [[Wikipedia:Microsoft|Microsoft]]'s [[Wikipedia:Microsoft_Windows_NT|Windows NT]] effort the '''ARC''' standard defines the byte order to be [[Endianess|little endian]] only.  [[Wikipedia:Silicon_Graphics|SGI]] systems where ARC is called '''ARCS''' violate that by being big endian.
 +
 +
=== Environment Variables ===
 +
 +
SGI ARCS has some additional variables further to ARC: ''netaddr'', ''console'', ''rbaud'', ''sgilogo'' e.t.c.
 +
 +
See: [http://techpubs.sgi.com/library/tpl/cgi-bin/browse.cgi?coll=0650&db=bks&cmd=toc&pth=/SGI_Admin/IA_ConfigOps IRIX Admin: System Configuration and Operation]. Chapter 9.
  
 
=== Constants ===
 
=== Constants ===
  
ARCS and ARC differs in some constatns:
+
ARCS and ARC differs in some (API) constants:
  
{| border="1" cellpadding="2"
+
{| {{PrettyTable}}
 
!Name
 
!Name
 
!ARCS
 
!ARCS
Line 64: Line 100:
 
=== SCSI Host ID ===
 
=== SCSI Host ID ===
  
On the most SGI's computers the default SCSI Host ID is 0 instead of 7.
+
On the most SGI's computers the default SCSI controller Host ID is 0 instead of 7.
  
 
See [http://www.faqs.org/faqs/sgi/faq/hardware/index.html SGI hardware Frequently Asked Questions (FAQ)], section 52.
 
See [http://www.faqs.org/faqs/sgi/faq/hardware/index.html SGI hardware Frequently Asked Questions (FAQ)], section 52.
Line 70: Line 106:
 
'''SCSI IDs''':
 
'''SCSI IDs''':
  
{| border="1" cellpadding="2"
+
{| {{PrettyTable}}
 
!Device
 
!Device
 
!ARCS
 
!ARCS
Line 97: Line 133:
  
 
The <code>scsi(0)disk(0)rdisk(0)partition(0)</code> on ARC is used to access a whole raw disk (like /dev/sda).
 
The <code>scsi(0)disk(0)rdisk(0)partition(0)</code> on ARC is used to access a whole raw disk (like /dev/sda).
 +
 +
ARCS systems use [[Disk Volume Header]] (DVH) as partition table for HDDs and CD-ROMs.
  
 
* [http://www.tldp.org/HOWTO/Partition/index.html Linux Partition HOWTO]
 
* [http://www.tldp.org/HOWTO/Partition/index.html Linux Partition HOWTO]
 
On a SGI's ARCS systems all disks (even CD) must have a IRIX volume header [http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=man&fname=/usr/share/catman/a_man/cat7/vh.z vh(7M)] 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.
 
 
* [http://packages.debian.org/unstable/utils/dvhtool dvhtool]
 
  
 
=== Boot-PROM ===
 
=== Boot-PROM ===
Line 120: Line 146:
 
SGI's [[Endianess|big endian]] ARCS can read SGI-disklabelled disks only. The <code>scsi(0)....partition(0)</code> is a valid name for the ''first'' partition and <code>scsi(0)....partition(8)</code> is a SGI Volume Header. This names are used as value for ARCS environment variables, i.e. for ''SystemPartition''.
 
SGI's [[Endianess|big endian]] ARCS can read SGI-disklabelled disks only. The <code>scsi(0)....partition(0)</code> is a valid name for the ''first'' partition and <code>scsi(0)....partition(8)</code> is a SGI Volume Header. This names are used as value for ARCS environment variables, i.e. for ''SystemPartition''.
  
SGI BOOT PROM uses own device naming scheme (old [http://www.netbsd.org/Ports/mipsco/ mipsco] monitor syntax?). The general format is:  
+
SGI BOOT [http://techpubs.sgi.com/library/tpl/cgi-bin/getdoc.cgi?coll=0650&db=bks&fname=/SGI_Admin/books/IA_ConfigOps/sgi_html/ch09.html&srch=prom PROM] uses own device naming scheme (old [http://www.netbsd.org/Ports/mipsco/ mipsco] monitor syntax?). The general format is:  
  
 
  <driver name> (<controller id>, <device id>, <partition>)  
 
  <driver name> (<controller id>, <device id>, <partition>)  
Line 132: Line 158:
 
* [http://oss.sgi.com/projects/xfs/ Project XFS Linux]
 
* [http://oss.sgi.com/projects/xfs/ Project XFS Linux]
  
== API ==
+
== ARC API ==
  
ARC BIOS provides a call vector table for the ARC BIOS services.
+
ARC BIOS provides an external API for "applications" like OS installers or second stage bootloaders.
  
  N  Offset Name
+
=== ARC SPB ===
00   0x00   Load
+
 
01   0x04   Invoke
+
System Parameter Block (SPB) is a data structure containing ARC variables and pointers. The 32-bit SPB structure is defined in the [ftp://ftp.linux-mips.org/pub/linux/mips/doc/ARC/riscspec.pdf ARC Standard document] p4.4.2 . System Parameter Block begins at physical address 0x1000 (0x80001000 KSEG0 cached, 0xa0001000 KSEG1 uncached)
02   0x08   Execute
+
 
03   0x0c   Halt
+
On a 64-bit ARC systems all SPB pointers are 64-bit. See an [[ARCLoad]] sources for more details.
04   0x10   PowerDown
+
 
05   0x14   Restart
+
=== Firmware call vector ===
06   0x18   Reboot
+
 
07   0x1c   EnterInteractiveMode
+
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.
08   0x20   ReturnFromMain
+
 
09   0x24   GetPeer
+
{| {{PrettyTable}}
10   0x28   GetChild
+
! || Offset || Name
11   0x2c   GetParent
+
|-
12   0x30   GetConfigurationData
+
| 00 || 0x00 || Load
13   0x34   AddChild
+
|-
14   0x38   DeleteComponent
+
| 01 || 0x04 || Invoke
15   0x3c   GetComponent
+
|-
16   0x40   SaveConfiguration
+
| 02 || 0x08 || Execute
17   0x44   GetSystemId
+
|-
18   0x48   GetMemoryDescriptor
+
| 03 || 0x0c || Halt
19   0x4c   Signal
+
|-
20   0x50   GetTime
+
| 04 || 0x10 || PowerDown
21   0x54   GetRelativeTime
+
|-
22   0x58   GetDirectoryEntry
+
| 05 || 0x14 ||  Restart
23   0x5c   Open
+
|-
24   0x60   Close
+
| 06 || 0x18 || Reboot
25   0x64   Read
+
|-
26   0x68   GetReadStatus
+
| 07 || 0x1c || EnterInteractiveMode
27   0x6c   Write
+
|-
28   0x70   Seek
+
| 08 || 0x20 || ReturnFromMain
29   0x74   Mount
+
|-
30   0x78   GetEnvironmentVariable
+
| 09 || 0x24 || GetPeer
31   0x7c   SetEnvironmentVariable
+
|-
32   0x80   GetFileInformation
+
| 10 || 0x28 || GetChild
33   0x84   SetFileInformation
+
|-
34   0x88   FlushAllCaches
+
| 11 || 0x2c || GetParent
35   0x8c   TestUnicodeCharacter
+
|-
36   0x90   GetDisplayStatus
+
| 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.
 
Note, there is no Unlink or Erase call.
  
 
== 32-bit vs. 64-bit ==
 
== 32-bit vs. 64-bit ==
The ARC standard understands itself as an environment for a 32-bit operating system.
+
The ARC standard was defined as an environment for 32-bit operating systems. In retrospect this may be considered a short-sighted decision, as indeed the [[R4000]] and [[Wikipedia:DEC_Alpha|DEC Alpha]] architectures were already in production at the time; nonetheless, in the early 1990s a 32-bit environment was deemed sufficient for small to medium sized systems by the authors of the ARC standard.
With the [[R4000]] and [[Wikipedia:DEC_Alpha|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 [[IP22|Power Indigo 2]], [[IP22|Indigo 2 R10000]], [[IP27|Origin]], [[IP27|Onyx 2]], [[IP30|Octane]] systems is known to be 64-bit.
+
As a result, most MIPS ARC firmware implementations are 32-bit; however, a few of the more recent implementations are 64-bit only.  An explanation of the exact way the 64-bit versions were implemented, as compared to the 32-bit versions, was never published.  The ARC firmwares on [[IP22|Power Indigo 2]], [[IP28|Indigo 2 R10000]], [[IP27|Origin]], [[IP27|Onyx 2]], [[IP30|Octane]] systems are known to be 64-bit.
 
+
There is a [[Load64]], second stage bootloader for [[IP30]].
+
  
 
== ECOFF and ELF support ==
 
== 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.
+
The ARC standard mandates [[ECOFF]] support only.  While appropriate for the UNIX flavours of the time--which were often still based on ECOFF--and also convenient for Windows NT, which uses [[Wikipedia:Portable Executable|PECOFF]] (a variant of ECOFF, in which an MSDOS .exe header is added to the beginning of ECOFF object files), nevertheless ECOFF is not appropriate for any modern flavor of UNIX, which usually are based on the [[ELF]] binary format.
 +
 
 +
However, because of this requirement in the ARC standard, 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 ===
 
=== Booting the kernel fails with PROM error messages ===
 +
The following bug has been observed:
 +
<pre>
 
   >> boot bootp()/vmlinux
 
   >> boot bootp()/vmlinux
 
   73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960
 
   73264+592+11520+331680+27848d+3628+5792 entry: 0x8df9a960
Line 196: Line 272:
 
   Cannot load bootp()/vmlinux
 
   Cannot load bootp()/vmlinux
 
   Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.
 
   Illegal f_magic number 0x7f45, expected MIPSELMAGIC or MIPSEBMAGIC.
 
+
</pre>
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.
+
This problem has been observed with Indys and with the [[RM_200]].  The ''elf2ecoff'' utility, which is part of the kernel source, allows conversion of an [[ELF]] kernel binary into a bootable [[ECOFF]] binary that can serve as a bootfile.  There is also the [[arcboot]] utility, which ships with recent Indy distributions, and which can boot an [[ELF]] kernel of an ext2 or ext3 filesystem when used as a first-stage boot loader.  Usually [[arcboot]] is the preferable solution.
  
 
== Milo/Pandora ==
 
== Milo/Pandora ==
Line 203: Line 279:
  
 
''Pandora'' is a simple monitor and debugger included with Milo.
 
''Pandora'' is a simple monitor and debugger included with Milo.
 +
 +
== Arcboot ==
 +
 +
[[Arcboot]] is a first stage bootloader that is able to load [[ELF|ELF32]] and [[ELF|ELF64]] kernel files from both ext2 and ext3 filesystems.
 +
 +
== ARCLoad ==
 +
All Linux/MIPS installations (most notably all [[IP27|Origin]], [[IP30|Octane]] and [[IP28|Indigo2 R10000]], which have 64-bit ARCS) can be loaded by [[ARCLoad]].
  
 
== Arcdiag ==
 
== Arcdiag ==
Line 214: Line 297:
 
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 [[Jazz|Olivetti M700-10]] where network booting is not supported at all.
 
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 [[Jazz|Olivetti M700-10]] where network booting is not supported at all.
  
=== Machine doesn't download the kernel when I try to netboot ===
+
=== SGI ARCS ping problem ===
 +
The ARCS shell ping command uses the <em>echo</em> service on port 7/UDP, not ICMP as one would expect for a UNIX system.  These days virtually all UNIX / Linux systems have that service disabled making them unpingable from the ARCS shell.  If you're running <em>xinetd</em> on <em>Fedora</em> the service can be enabled by <tt>chkconfig echo-dgram on</tt>; similar for other distributions.
 +
 
 +
=== 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]].
 
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 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
+
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
 
   echo 1 > /proc/sys/net/ipv4/ip_no_pmtu_disc
Line 224: Line 311:
 
as root on the boot server.  Alternatively you can also add this setting to /etc/sysctl.conf.
 
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 ===
+
==== 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
 
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
Line 231: Line 318:
  
 
on the server.  This problem has been observed on [[IP22|SGI IP22]] and [[RM_200|Siemens-Nixdorf RM200]] systems.
 
on the server.  This problem has been observed on [[IP22|SGI IP22]] and [[RM_200|Siemens-Nixdorf RM200]] systems.
 +
 +
==== 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 <tt>-R from:to</tt> 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 ===
 
=== 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.
 
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.
 +
 +
[[Category:ARC]]
 +
[[Category:SGI]]

Latest revision as of 10:57, 18 October 2010

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.

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.

Environment Variables

SGI ARCS has some additional variables further to ARC: netaddr, console, rbaud, sgilogo e.t.c.

See: IRIX Admin: System Configuration and Operation. Chapter 9.

Constants

ARCS and ARC differs in some (API) constants:

Name ARCS ARC
CLASS_MemoryClass 3 6
CLASS_AdapterClass 4 3
CLASS_ControllerClass 5 4
CLASS_PeripheralClass 6 5
MEM_FreeContiguous 2 7
MEM_FreeMemory 3 2
MEM_BadMemory 4 3
MEM_LoadedProgram 5 4
MEM_FirmwareTemporary 6 5
MEM_FirmwarePermanent 7 6

SCSI Host ID

On the most SGI's computers the default SCSI controller Host ID is 0 instead of 7.

See SGI hardware Frequently Asked Questions (FAQ), section 52.

SCSI IDs:

Device ARCS ARC
Controller 0 7
Disk #1 1 0
CD-ROM 4 6
Tape 7 ?

Drive Partitions

ARC systems uses MS-DOS MBR partition layout for hard drives and conventional ISO-9660 for CD-ROMs.

The scsi(0)disk(0)rdisk(0)partition(0) on ARC is used to access a whole raw disk (like /dev/sda).

ARCS systems use Disk Volume Header (DVH) as partition table for HDDs and CD-ROMs.

Boot-PROM

Little endian ARC BIOS can access files on a MS-DOS partitioned and FAT-12/16 formatted disks and on ISO-9660 CDFS CD-ROMs.

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.

SGI BOOT PROM uses own device naming scheme (old mipsco monitor syntax?). The general format is:

<driver name> (<controller id>, <device id>, <partition>) 

Both harddisk and CD-ROM use dksc as device name. To load the standalone shell (sashARCS) from the CD-ROM's Volume Header filesystem, enter the Command Monitor from the PROM menu and type :

boot -f dksc(0,4,8)sashARCS

ARC API

ARC BIOS provides an external API for "applications" like OS installers or second stage bootloaders.

ARC SPB

System Parameter Block (SPB) is a data structure containing ARC variables and pointers. The 32-bit SPB structure is defined in the ARC Standard document p4.4.2 . System Parameter Block begins at physical address 0x1000 (0x80001000 KSEG0 cached, 0xa0001000 KSEG1 uncached)

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 was defined as an environment for 32-bit operating systems. In retrospect this may be considered a short-sighted decision, as indeed the R4000 and DEC Alpha architectures were already in production at the time; nonetheless, in the early 1990s a 32-bit environment was deemed sufficient for small to medium sized systems by the authors of the ARC standard.

As a result, most MIPS ARC firmware implementations are 32-bit; however, a few of the more recent implementations are 64-bit only. An explanation of the exact way the 64-bit versions were implemented, as compared to the 32-bit versions, was never published. The ARC firmwares on Power Indigo 2, Indigo 2 R10000, Origin, Onyx 2, Octane systems are 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 were often still based on ECOFF--and also convenient for Windows NT, which uses PECOFF (a variant of ECOFF, in which an MSDOS .exe header is added to the beginning of ECOFF object files), nevertheless ECOFF is not appropriate for any modern flavor of UNIX, which usually are based on the ELF binary format.

However, because of this requirement in the ARC standard, 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

The following bug has been observed:

   >> 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 the RM_200. The elf2ecoff utility, which is part of the kernel source, allows conversion of an ELF kernel binary into a bootable ECOFF binary that can serve as a bootfile. There is also the arcboot utility, which ships with recent Indy distributions, and which can boot an ELF kernel of an ext2 or ext3 filesystem when used as a first-stage boot loader. 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.

ARCLoad

All Linux/MIPS installations (most notably all Origin, Octane and Indigo2 R10000, which have 64-bit ARCS) can be loaded by ARCLoad.

Arcdiag

The arcdiag diagnostic utility is an example of the ARC MIPS standalone application.

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.

SGI ARCS ping problem

The ARCS shell ping command uses the echo service on port 7/UDP, not ICMP as one would expect for a UNIX system. These days virtually all UNIX / Linux systems have that service disabled making them unpingable from the ARCS shell. If you're running xinetd on Fedora the service can be enabled by chkconfig echo-dgram on; similar for other distributions.

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

echo 4096 32767 > /proc/sys/net/ipv4/ip_local_port_range

on the server. This problem has been observed on SGI IP22 and Siemens-Nixdorf RM200 systems.

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.