Re: 512M RAM support

To: "Matt Thomas" <matt%3am-software.com@localhost>, "Allen Briggs" <briggs%wasabisystems.com@localhost>

Subject: Re: 512M RAM support

From: "Boo Geum Jung" <bgjung%etri.re.kr@localhost>

Date: Thu, 4 Jul 2002 20:59:34 +0900

Title: Re: 512M RAM support

Thank you very much for your help.
I tried with it, but I have still some problems.
It seems to work well, ... but it falls into some unstable state.
It recognized 512M correctly.
And it always run perfectly before multiuser mode using nfs.
But when entering into multiuser mode with "exit" command under # prompt,
it stops a ceratin point, it's not fixed point.
Once it stopped after "Checking for core dump...", and once after
"savecore: no core dump (no dumpdev)" and
once it stopped at displaying "Copyright ...".
I modified sandpoint/include/vmparam.h as
"#define VM_MAX_KERNEL_ADDRESS   (VM_MIN_KERNEL_ADDRESS + 2 * SEGMENT_LENGTH - 1)"
and add upper 256M BAT mapping in sandpoint/machdep.c just as below
/* map the upper 256M area */
        battable[3].batl = BATL(0x10000000, BAT_M, BAT_PP_RW);
        battable[3].batu = BATU(0x10000000, BAT_BL_256M, BAT_Vs);
asm volatile ("mtibatl 3,%0; mtibatu 3,%1"
                      :: "r"(battable[3].batl), "r"(battable[3].batu));
asm volatile ("mtdbatl 3,%0; mtdbatu 3,%1"
                      :: "r"(battable[3].batl), "r"(battable[3].batu));

Under all these changes, 256M works perfect as before.

----- Original Message -----

From: Matt Thomas

To: Allen Briggs

Cc: Boo Geum Jung ; port-powerpc%netbsd.org@localhost

Sent: Wednesday, June 26, 2002 3:58 AM

Subject: Re: 512M RAM support

At 06:52 AM 6/17/2002, Allen Briggs wrote:
>On Mon, Jun 17, 2002 at 12:11:19AM -0700, Matt Thomas wrote:
> > It's not that simple. In fact, a bunch of changes need to made.
> > I'll try to get that committed sometime this week. I have those
> > changes done for 1.5.
>
>I assume these are changes to allow the kernel to occupy and use
>more than 256MB, correct? I'd like to see your changes posted here
>as a diff before they're committed. I expect that there are both
>platform-specific and generic powerpc parts to the changes. Is
>this correct?
>
>-allen

No platform specific stuff is needed. Just a few extra defines and
changes to trap_subr.S (I've avoided trap_subr_mp.S since that really
should be merged into trap_subr.S). mpc6xx/pmap.c already has the
requisite code to initialize KERNEL2_SR.

Index: include/mpc6xx/vmparam.h
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/powerpc/include/mpc6xx/vmparam.h,v
retrieving revision 1.1
diff -u -r1.1 vmparam.h
--- include/mpc6xx/vmparam.h    2001/06/06 17:36:03     1.1
+++ include/mpc6xx/vmparam.h    2002/06/25 18:52:27
@@ -106,25 +106,29 @@
   */
#if 0
/*
- * Move the SR# to the top 4 bits to make the lower 19bits entirely random
+ * Move the SR# to the top 4 bits to make the lower 20 bits entirely random
   * so to give better PTE distribution.
   */
#define        VSID_MAKE(sr, hash)     (((sr) <<
(ADDR_SR_SHFT-4))|((hash) & 0xfffff))
#define        VSID_TO_SR(vsid)        (((vsid) >> (ADDR_SR_SHFT-4)) & 0xF)
#define        VSID_TO_HASH(vsid)      ((vsid) & 0xfffff)
+#define        VSID_SR_INCREMENT       0x00100000
#else
#define        VSID_MAKE(sr, hash)     ((sr) | (((hash) & 0xfffff) << 4))
#define        VSID_TO_SR(vsid)        ((vsid) & 0xF)
#define        VSID_TO_HASH(vsid)      (((vsid) >> 4) & 0xfffff)
+#define        VSID_SR_INCREMENT       0x00000001
#endif

/*
   * Fixed segments
   */
-#define        USER_SR                 13
-#define        KERNEL_SR               14
+#define        USER_SR                 (KERNEL_SR-1)
+#define        KERNEL_SR               (KERNEL2_SR-1)
+#define        KERNEL2_SR              14
#define        KERNEL_VSIDBITS         0xfffff
#define        KERNEL_SEGMENT          VSID_MAKE(KERNEL_SR, KERNEL_VSIDBITS)
+#define        KERNEL2_SEGMENT         VSID_MAKE(KERNEL2_SR, KERNEL_VSIDBITS)
#define        EMPTY_SEGMENT           VSID_MAKE(0, KERNEL_VSIDBITS)
#define        USER_ADDR               ((void *)(USER_SR << ADDR_SR_SHFT))

@@ -144,7 +148,7 @@
#define        VM_MAXUSER_ADDRESS      ((vaddr_t) 0x7ffff000)
#define        VM_MAX_ADDRESS          VM_MAXUSER_ADDRESS
#define        VM_MIN_KERNEL_ADDRESS   ((vaddr_t) (KERNEL_SR <<
ADDR_SR_SHFT))
-#define        VM_MAX_KERNEL_ADDRESS   (VM_MIN_KERNEL_ADDRESS +
SEGMENT_LENGTH)
+#define        VM_MAX_KERNEL_ADDRESS   (VM_MIN_KERNEL_ADDRESS +
2*SEGMENT_LENGTH)

#ifndef VM_PHYSSEG_MAX
#define        VM_PHYSSEG_MAX          16
Index: powerpc/trap_subr.S
===================================================================
RCS file: /cvsroot/syssrc/sys/arch/powerpc/powerpc/trap_subr.S,v
retrieving revision 1.21
diff -u -r1.21 trap_subr.S
--- powerpc/trap_subr.S 2002/05/02 16:47:49     1.21
+++ powerpc/trap_subr.S 2002/06/25 18:52:28
@@ -672,6 +672,8 @@
         mtsr    USER_SR,3;                                              \
         lwz     3,PM_KERNELSR(2);                                       \
         mtsr    KERNEL_SR,3;                                            \
+       lwz     3,PM_KERNEL2SR(2);                                      \
+       mtsr    KERNEL2_SR,3;                                           \
         CPU601_KERN_LEAVE(2,3);                                         \
1:     mfsprg 2,1;                    /* restore cr */                \
         mtcr    2;                                                      \
@@ -712,6 +714,9 @@
         lis     31,KERNEL_SEGMENT@h
         ori     31,31,KERNEL_SEGMENT@l
         mtsr    KERNEL_SR,31
+       lis     31,KERNEL2_SEGMENT@h
+       ori     31,31,KERNEL2_SEGMENT@l
+       mtsr    KERNEL2_SR,31
         CPU601_KERN_ENTRY(30,31)
/* Obliterate SRs so BAT spills work correctly */
         lis     31,EMPTY_SEGMENT@h
@@ -885,6 +890,9 @@
         lis     3,(KERNEL_SEGMENT|SR_SUKEY|SR_PRKEY)@h;                 \
         ori     3,3,(KERNEL_SEGMENT|SR_SUKEY|SR_PRKEY)@l;               \
         mtsr    KERNEL_SR,3;                                            \
+       lis     3,(KERNEL2_SEGMENT|SR_SUKEY|SR_PRKEY)@h;                \
+       ori     3,3,(KERNEL2_SEGMENT|SR_SUKEY|SR_PRKEY)@l;              \
+       mtsr    KERNEL2_SR,3;                                           \
99:    mfmsr   5;                                                      \
         ori     5,5,(PSL_IR|PSL_DR|PSL_RI);                             \
         mtmsr   5;                                                      \
@@ -940,6 +948,8 @@
         mtsr    7,4                     /* Restore SR7 */
         lwz     4,PM_KERNELSR(3)
         mtsr    KERNEL_SR,4             /* Restore kernel SR */
+       lwz     4,PM_KERNEL2SR(3)
+       mtsr    KERNEL2_SR,4            /* Restore kernel SR2 */
         CPU601_KERN_LEAVE(3,4)
         lis     3,_C_LABEL(astpending)@ha /* Test AST pending */
         lwz     4,_C_LABEL(astpending)@l(3)

--
Matt Thomas               Internet:   matt%3am-software.com@localhost
3am Software Foundry      WWW URL:    http://www.3am-software.com/bio/matt/
Cupertino, CA             Disclaimer: I avow all knowledge of this message

References:

Re: 512M RAM support
- From: Matt Thomas