Subject: Re: [PATCH] Highmem detection for Indigo2

From: Keith M Wesolowski <[email-masked]>
Date: Wed, 7 May 2003 23:11:17 -0700

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.

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)

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.

-- 
Keith M Wesolowski <[email-masked]> http://foobazco.org/~wesolows
------(( Project Foobazco Coordinator and Network Administrator ))------
	"May Buddha bless all stubborn people!"
				-- Uliassutai Karakorum Blake

---

From: Ladislav Michl <[email-masked]>
Date: Thu, 8 May 2003 09:32:00 +0200

> This is a pretty unfortunate choice of names for this function.  See

what about probe_memory or detect_memory?

>  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
  
> 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

---

From: Guido Guenther <[email-masked]>
Date: Thu, 8 May 2003 10:50:04 +0200

> not sure is this way will be acceptale for him...
Having what the ARC spec calls "System Configuration Data" in a tree
like structure would be a nice thing, I think. I have some code for this
around here but wanted to check sysfs in 2.5 to see if it eases up the
representation - we could finally properly detect the primary graphics
board with that.
 -- Guido

---

From: Guido Guenther <[email-masked]>
Date: Thu, 8 May 2003 10:58:15 +0200

> xdm, but I get that without the patch also.
That's xdm reading heaps of data from /dev/mem blindly (touching regions
it better shouldn't read from) for prng purposes. We had a fix in
Debian's xdm, hope the problem didn't creep back in. What X are you
running?
 -- Guido

---

From: Keith M Wesolowski <[email-masked]>
Date: Thu, 8 May 2003 09:40:22 -0700

> Debian's xdm, hope the problem didn't creep back in. What X are you

This is from Debian - 4.1.0-16.

---

From: Guido Guenther <[email-masked]>
Date: Thu, 8 May 2003 19:00:51 +0200

> This is from Debian - 4.1.0-16.
The changes went into 4.2.1-4 at 18 Nov 2002.
 -- Guido

---

From: Ralf Baechle <[email-masked]>
Date: Fri, 9 May 2003 21:08:23 +0200

> especially in a 64-bit kernel.  ARC[S] really does seem to be useless.

That's what I'm saying since '94.  ARC was a commitee approach of the
ACE consortium which soon died.  The firmware part of the ARC standard
was also published as the Microsoft Portable Bootloader Standard but
Today every ARC implementation has some major deviations from the
standard rendering the term standard into nothing but a cynic demonation ...

  Ralf