Difference between revisions of "ARC"
(→32-bit vs. 64-bit: change Indigo2 R10000 to IP28)
m (SGI Category)
|(One intermediate revision by one other user not shown)|
|Line 298:||Line 298:|
=== SGI ARCS ping problem ===
=== 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
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 by <tt>chkconfig echo-dgram on</tt>; similar for other distributions.
=== TFTP Problems ===
=== TFTP Problems ===
|Line 330:||Line 330:|
Latest revision as of 10:57, 18 October 2010
- 1 The ARC Standard
- 2 ARC Path Naming Convention
- 3 Environment Variables
- 4 ARC vs ARCS
- 5 ARC API
- 6 32-bit vs. 64-bit
- 7 ECOFF and ELF support
- 8 Milo/Pandora
- 9 Arcboot
- 10 ARCLoad
- 11 Arcdiag
- 12 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.
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.
|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
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.
ARCS and ARC differs in some (API) constants:
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.
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).
ARCS systems use Disk Volume Header (DVH) as partition table for HDDs and 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.
<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 BIOS provides an external API for "applications" like OS installers or second stage bootloaders.
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.
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.
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.
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.
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 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
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 email@example.com and firstname.lastname@example.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.