In article <050417130019.M0115255@mirage.ceres.dti.ne.jp>
I wrote:

> According to the ARC specification, these values are actually
> defined as ULONG or LONG, and our paddr_t is an integer type
> which represents physical address range (not equal to pointer
> width or VA range), so I'll commit the attached changes.
> (While here, I'll also change some unsigned long to u_long for consistency)

I've committed these changes.
If you see any problem (especially on ip30boot), please let me know.

BTW, does anyone tried ip3xboot with recent sources and toolchains?
On my O2, the firmware fails to load it:
---
System Maintenance Menu

1) Start System
2) Install System Software
3) Run Diagnostics
4) Recover System
5) Enter Command Monitor

Option? 5
Command Monitor.  Type "exit" to return to the menu.
> boot

Cannot load pci(0)scsi(0)disk(1)rdisk(0)partition(8)/boot.
Text start 0x0, size 0xd7b0 doesn't fit in a FreeMemory area.
Unable to execute pci(0)scsi(0)disk(1)rdisk(0)partition(8)/boot:  not enough space
Unable to load pci(0)scsi(0)disk(1)rdisk(0)partition(8)/boot: not enough space
> 
---

ip3xboot binary extracted from 2.0.2 base.tgz works,
and -current ip3xboot linked with "-N" (linked as OMAGIC)
also works. I guess the problem is caused by newer binutils,
but is it OK to apply the attached patch? comments?
---
Izumi Tsutsui


Index: Makefile
===================================================================
RCS file: /cvsroot/src/sys/arch/sgimips/stand/boot/Makefile,v
retrieving revision 1.9
diff -u -r1.9 Makefile
--- Makefile	1 Mar 2005 00:20:09 -0000	1.9
+++ Makefile	20 Apr 2005 17:04:20 -0000
@@ -24,7 +24,7 @@
 .include "../Makefile.booters"
 
 ip3xboot: ${OBJS} ${LIBS}
-	${LD} -Map boot.map -x -Ttext ${LOAD_ADDRESS_IP32} ${LDBUG} \
+	${LD} -Map boot.map -N -x -Ttext ${LOAD_ADDRESS_IP32} ${LDBUG} \
 	    -e start -o ip3xboot ${OBJS} ${LIBS}
 	@${STRIP} -s ip3xboot
 	@${SIZE} ip3xboot