Linux MIPS Architecture development
 help / color / mirror / Atom feed
From: Ladislav Michl <ladis@linux-mips.org>
To: Keith M Wesolowski <wesolows@foobazco.org>
Cc: linux-mips@linux-mips.org, Guido Guenther <agx@sigxcpu.org>
Subject: Re: [PATCH] Highmem detection for Indigo2
Date: Thu, 8 May 2003 09:32:00 +0200	[thread overview]
Message-ID: <20030508073200.GA837@kopretinka> (raw)
In-Reply-To: <20030508061117.GA30191@foobazco.org>

On Wed, May 07, 2003 at 11:11:17PM -0700, Keith M Wesolowski wrote:
> On Mon, Apr 28, 2003 at 09:16:39AM +0200, Ladislav Michl wrote:
> 
> > Following patch builds whole RAM map based of MC's memory configuration
> > registers, does some samity checks adds high system memory (if any) to
> > bootmem.
> 
> > +static void init_bootmem(void)
> ...
> > +	init_bootmem();
> 
> This is a pretty unfortunate choice of names for this function.  See
> mm/bootmem.c.

what about probe_memory or detect_memory?

> Other than that, your patch works fine for me; my Indy has 192MB
> memory and it's detected properly.  I do get an oops in do_be from
> xdm, but I get that without the patch also.
> 
> Determined physical RAM map:
>  memory: 00001000 @ 00000000 (reserved)
>  memory: 00001000 @ 00001000 (reserved)
>  memory: 001e1000 @ 08002000 (reserved)
>  memory: 0055d000 @ 081e3000 (usable)
>  memory: 000c0000 @ 08740000 (ROM data)
>  memory: 0b800000 @ 08800000 (usable)

that's not relevant part. information from memconfig registers is
printed above "Determined physical RAM map" [1]
MC: Probing memory configuration:
 Bank0:  32M @ 10000000
 Bank1: 128M @ 08000000
  
> I need to do the same kind of thing for ip32 as the ARC memory
> detection has the same shortcoming on that platform.  No sense having
> a machine support 1GB memory and only looking for 256MB of it,
> especially in a 64-bit kernel.  ARC[S] really does seem to be useless.

[1] This patch still uses ARCS to determine low 256M of memory, because
Indy can't have more anyway, it is useful only for FullHouse machines.
Purpose of this patch is to detect memory above 0x20000000. Idea was to
let people test if memconfig registers provides relevant informations
and then get rid of ARCS based memory probing completely. Kernel
reserves its memory itself and we know where exceptions vectors are (do
i need reserve space for them explicitly?), so the only problem is ARCS
data (it's not possible to detect where ARCS stores them without asking
it). If no ARCS call will be made after mm initialization (thoose few
remaining is easy to avoid) this should be also no problem.

Guido told me he is working device detection based on ARCS calls. I'm
not sure is this way will be acceptale for him...

	ladis

  reply	other threads:[~2003-05-08  7:46 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-04-28  7:16 [PATCH] Highmem detection for Indigo2 Ladislav Michl
2003-05-08  6:11 ` Keith M Wesolowski
2003-05-08  7:32   ` Ladislav Michl [this message]
2003-05-08  8:50     ` Guido Guenther
2003-05-08  8:58     ` Guido Guenther
2003-05-08 16:40       ` xdm oopses Keith M Wesolowski
2003-05-08 17:00         ` Guido Guenther
2003-05-09 19:08   ` [PATCH] Highmem detection for Indigo2 Ralf Baechle

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=20030508073200.GA837@kopretinka \
    --to=ladis@linux-mips.org \
    --cc=agx@sigxcpu.org \
    --cc=linux-mips@linux-mips.org \
    --cc=wesolows@foobazco.org \
    /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