[palinux-palo] bug#31: Hack for palo with >= 2G RAM

X-PA-RISC Linux-PR-Message: report 31
X-PA-RISC Linux-PR-Package: palo
X-Loop: daniel_frazier@hp.com
Received: via spool by 31-bugs@bugs.parisc-linux.org id=B31.98218986324623
          (code B ref 31); Wed, 14 Feb 2001 22:33:02 GMT
Message-Id: <m14T9id-001VpZC@bame.riverrock.org>
From: bame@riverrock.org
Errors-To: bame@riverrock.org
To: parisc-linux-cvs@parisc-linux.org, 31@bugs.parisc-linux.org
Date: Wed, 14 Feb 2001 14:44:11 -0700
Sender: bame@bame.riverrock.org


When palo's stack and heap got moved up to the top of the first memory
module, things went wrong for machines with >= 2G ram.  The culprit
appears to be
sign extension into the upper half of the double-word registers.  Perhaps
palo could be changed to prevent this sign extension, but for now it's
easier to limit the "top" of RAM to 1G.  This still allows for a
more than generous ram disk while also using small-ram boxes efficiently.

Index: crt0.S
===================================================================
RCS file: /home/cvs/parisc/palo/ipl/crt0.S,v
retrieving revision 1.10
retrieving revision 1.11
diff -u -r1.10 -r1.11
--- crt0.S	2001/02/09 04:06:22	1.10
+++ crt0.S	2001/02/14 21:31:44	1.11
@@ -45,6 +45,16 @@
 	ldo	R%(IMM_MAX_MEM)(%r3), %r3
 	ldw	0(%r3), %r3
 
+	/* due to sign extension problems and PDC, limit RAM to 1G */
+	/* this isn't efficient assembly but it doesn't matter here either */
+#define ARTIFICIAL_LIMIT (1*1024*1024*1024)
+	ldil	L%(ARTIFICIAL_LIMIT), %r4
+	ldo	R%(ARTIFICIAL_LIMIT)(%r4), %r4
+	cmpb,<<	%r3, %r4, limit_ok
+	nop
+	copy	%r4, %r3
+
+limit_ok:
 	/* stack is at top of initial mem module */
 #define STACK_SIZE (64 * 1024)
 	ldil	L%(STACK_SIZE), %r4