Difference between revisions of "ARC"

From LinuxMIPS
Jump to: navigation, search
Line 4: Line 4:
 
== Endianess ==
 
== Endianess ==
 
For the ease of [http://en.wikipedia.org/wiki/Microsoft Microsoft]'s [http://en.wikipedia.org/wiki/Microsoft_Windows_NT 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.
 
For the ease of [http://en.wikipedia.org/wiki/Microsoft Microsoft]'s [http://en.wikipedia.org/wiki/Microsoft_Windows_NT 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.
 +
 +
== 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 [[RM200]].  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.
  
 
== Network Booting ==
 
== Network Booting ==

Revision as of 01:32, 4 November 2004

The ARC Standard

was born in the early 90s as part of the Advanced Computing Environment 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.

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.

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 RM200. 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.

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.

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

This problem has been observed with the ARC firmware of SNI RM200 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

  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 2048 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.

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.