Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Jeff Harrell <jharrell@ti.com>
To: linux-mips@oss.sgi.com
Subject: Question concerning discontinuities in memory map.
Date: Fri, 25 Aug 2000 16:50:15 -0600	[thread overview]
Message-ID: <39A6F826.D444E0@ti.com> (raw)


[-- Attachment #1.1: Type: text/plain, Size: 2306 bytes --]

I have a question concerning a discontinuity in my memory map.  The
development board that I am
working on currently has the start of its SDRAM at 0x14000000 (physical
memory).  It looks like a
lot of the code is written under the assumption that the base of the
kernel will be at 0x80000000.  I
have had to modify several sections of code to handle this discontinuity
with respect to max_low_pfn,
high_memory, num_physpages  max_mapnr, and low (/arch/mips/mm/init.c).
These variables seem
to use the PAGE_SHIFT variable to locate the start of that page in
physical memory: (e.g.,   max_mapnr
<< PAGE_SHIFT).  It looks like a lot of the problem stems from
max_low_pfn.  In init_bootmem_core:

----8<  snippet from init_bootmem_core ( mm/bootmem.c) 8<----------

     static unsigned long __init init_bootmem_core (bootmem_data_t
     *bdata,
               unsigned long mapstart, unsigned long start,
     unsigned long end)
       {
               unsigned long mapsize = ((end - start)+7)/8;

               mapsize = (mapsize + (sizeof(long) - 1UL)) &
     ~(sizeof(long) - 1UL);
               bdata->node_bootmem_map = phys_to_virt(mapstart <<
     PAGE_SHIFT);
               bdata->node_boot_start = (start << PAGE_SHIFT);
               bdata->node_low_pfn = end;
       ...

----------------------------------------------------

the mapsize is defined by end-start, where start is the _end
(kernel_end) + bootmap_size.
therefore it looks like end should represent the end of memory (i.e.
SDRAM).  In our case
this is 0x15FFFFFF (i.e. 32M).  If I let the rest of the kernel process
max_low_pfn and the
associated variable normally,  the paging routines will calculate that I
have 335M of memory!
I seem to be chasing this problem through the kernel.  Is there a
central place in the code that
would handle the offset properly?  I don't think I have caught all of
the implications of this change
yet because I am still failing in the paging routines.  Any information
that is available on how this
can be accomplished would be greatly appreciated.

Thanks,
Jeff

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Jeff Harrell                    Work:  (801) 619-6104
Broadband Access group/TI       Cell:  (801) 597-6268
jharrell@ti.com
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~



[-- Attachment #1.2: Type: text/html, Size: 3242 bytes --]

[-- Attachment #2: Card for Jeff Harrell --]
[-- Type: text/x-vcard, Size: 376 bytes --]

begin:vcard 
n:Harrell;Jeff
tel;cell:(801) 597-6268
tel;fax:(801) 619-6150
tel;work:(801) 619-6104
x-mozilla-html:TRUE
url:http://www.ti.com
org:Broadband Access Group
version:2.1
email;internet:jharrell@ti.com
title:Texas Instruments
adr;quoted-printable:;;170 West Election Rd. Suite 100	=0D=0AMS 4106		;Draper;Utah;84020-6410;USA
x-mozilla-cpt:;0
fn:Jeff Harrell
end:vcard

                 reply	other threads:[~2000-08-25 22:41 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=39A6F826.D444E0@ti.com \
    --to=jharrell@ti.com \
    --cc=linux-mips@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox