HIGHMEM now working

HIGHMEM now working

[Tilmann Bitterberg]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 761 bytes --]

Hi Paul, $LIST

I managed to get CONFIG_HIGHMEM to work on CHRP. What I
basically did is to move the HIGHMEM area down from 0xfe to
0xf6. See my patch against the 2.4.0-test9 kernel.org kernel
below. I tested this patch on a 44P-270 with 3GB, a 44P-170
with 1GB and a 43P-150 with 512MB.

On the 150 I faked HIGHEM with MAX_LOW_MEM == 256MB because
I don't have a box with more RAM in it. It worked fine.

I saw that you recently did some fixes for HIGHMEM on CHRP, but
they did not work. Actually, I can't get the kernel to boot on a
270. It dies in 'c01d9ff0 D init_task_union',
but anyway it won't even without HIGHMEM enabled, it didn't pass
'python_pcibios_read_config_byte'.

Why not just lower PKMAP_BASE to 0xf6000000, will this break
someone?

Tilmann

[-- Attachment #2: my highmem stuff --]
[-- Type: TEXT/PLAIN, Size: 4745 bytes --]

diff -ur linux-2.4-normal/arch/ppc/kernel/chrp_pci.c linux-2.4-highmem/arch/ppc/kernel/chrp_pci.c
--- linux-2.4-normal/arch/ppc/kernel/chrp_pci.c	Wed Oct 11 10:55:46 2000
+++ linux-2.4-highmem/arch/ppc/kernel/chrp_pci.c	Tue Oct 10 10:06:41 2000
@@ -446,7 +446,8 @@
 				isa_mem_base = 0xa0000000;
 				isa_io_base = 0x88000000;
 			} else if ( !strncmp("IBM,7043-260", name, 12)
-				    || !strncmp("IBM,7044-270", name, 12))
+			         || !strncmp("IBM,7044-170", name, 12)
+			         || !strncmp("IBM,7044-270", name, 12))
 			{
 				pci_dram_offset = 0x0;
 				isa_mem_base = 0xc0000000;
diff -ur linux-2.4-normal/arch/ppc/mm/init.c linux-2.4-highmem/arch/ppc/mm/init.c
--- linux-2.4-normal/arch/ppc/mm/init.c	Wed Oct 11 10:55:46 2000
+++ linux-2.4-highmem/arch/ppc/mm/init.c	Fri Oct 13 11:15:14 2000
@@ -955,6 +962,8 @@
 #ifdef CONFIG_HIGHMEM
 	if (total_lowmem > MAX_LOW_MEM) {
 		total_lowmem = MAX_LOW_MEM;
+		printk(KERN_NOTICE "%ldMB HIGHMEM available.\n",
+			pages_to_mb((total_memory - total_lowmem)>>PAGE_SHIFT));
 		mem_pieces_remove(&phys_avail, total_lowmem,
 				  total_memory - total_lowmem, 0);
 	}
@@ -1249,8 +1261,9 @@
 unsigned long __init pmac_find_end_of_memory(void)
 {
 	unsigned long a, total;
+#ifndef CONFIG_HIGHMEM
 	unsigned long ram_limit = 0xe0000000 - KERNELBASE;
-
+#endif /* ndef CONFIG_HIGHMEM */
 	memory_node = find_devices("memory");
 	if (memory_node == NULL) {
 		printk(KERN_ERR "can't find memory node\n");
@@ -1274,12 +1287,14 @@
 	a = phys_mem.regions[0].address;
 	if (a != 0)
 		panic("RAM doesn't start at physical address 0");
+#ifndef CONFIG_HIGHMEM /* tibit */
 	if (__max_memory == 0 || __max_memory > ram_limit)
 		__max_memory = ram_limit;
 	if (phys_mem.regions[0].size >= __max_memory) {
 		phys_mem.regions[0].size = __max_memory;
 		phys_mem.n_regions = 1;
 	}
+#endif /* ndef CONFIG_HIGHMEM */
 	total = phys_mem.regions[0].size;
 	
 	if (phys_mem.n_regions > 1) {
@@ -1440,12 +1455,11 @@
 static void __init hash_init(void)
 {
 	int Hash_bits, mb, mb2;
-	unsigned int hmask, ramsize, h;
+	unsigned int hmask, ramsize = (ulong)end_of_DRAM - KERNELBASE;
 
 	extern unsigned int hash_page_patch_A[], hash_page_patch_B[],
 		hash_page_patch_C[], hash_page[];
 
-	ramsize = (ulong)end_of_DRAM - KERNELBASE;
 #ifdef CONFIG_PPC64BRIDGE
 	/* The hash table has already been allocated and initialized
 	   in prom.c */
@@ -1458,6 +1472,7 @@
 	mb2 = 25 - Hash_bits;
 
 #else /* CONFIG_PPC64BRIDGE */
+	unsigned int h;
 
 	if ( ppc_md.progress ) ppc_md.progress("hash:enter", 0x105);
 	/*
@@ -1498,7 +1513,7 @@
 		Hash = 0;
 #endif /* CONFIG_PPC64BRIDGE */
 
-	printk("Total memory = %dMB; using %ldkB for hash table (at %p)\n",
+	printk("Total low memory = %dMB; using %ldkB for hash table (at %p)\n",
 	       ramsize >> 20, Hash_size >> 10, Hash);
 	if ( Hash_size )
 	{
diff -ur linux-2.4-normal/drivers/input/keybdev.c linux-2.4-highmem/drivers/input/keybdev.c
--- linux-2.4-normal/drivers/input/keybdev.c	Thu Jul 27 20:36:54 2000
+++ linux-2.4-highmem/drivers/input/keybdev.c	Wed Oct  4 07:59:20 2000
@@ -133,8 +133,11 @@
 {
 	if (type != EV_KEY) return;
 
+#if defined(CONFIG_ADB_KEYBOARD)
+
 	if (emulate_raw(code, down))
 		printk(KERN_WARNING "keyboard.c: can't emulate rawmode for keycode %d\n", code);
+#endif
 
 	tasklet_schedule(&keyboard_tasklet);
 }
diff -ur linux-2.4-normal/include/asm-ppc/highmem.h linux-2.4-highmem/include/asm-ppc/highmem.h
--- linux-2.4-normal/include/asm-ppc/highmem.h	Wed Oct 11 10:55:51 2000
+++ linux-2.4-highmem/include/asm-ppc/highmem.h	Fri Oct 13 17:02:30 2000
@@ -22,6 +22,7 @@
 
 #ifdef __KERNEL__
 
+#include <linux/config.h>
 #include <linux/init.h>
 #include <linux/interrupt.h>
 #include <asm/kmap_types.h>
@@ -41,13 +42,26 @@
  * easily, subsequent pte tables have to be allocated in one physical
  * chunk of RAM.
  */
+
+/*
+ * XXX: On CHRP, we cannot use the "normal" highmem area from 0xfe000000 to
+ * 0xffffffff because we have that particular area directly mapped with a BAT.
+ * So we just move it a litte bit down. We need a more flexible way to do that.
+ * -- tibit
+ */
+
+#if 1
+#define PKMAP_BASE (0xf6000000UL)
+#define KMAP_FIX_BEGIN	(0xf6400000UL)
+#else
 #define PKMAP_BASE (0xfe000000UL)
+#define KMAP_FIX_BEGIN  (0xfe400000UL)
+#endif /* CONFIG_POWER3 */
 #define LAST_PKMAP 1024
 #define LAST_PKMAP_MASK (LAST_PKMAP-1)
 #define PKMAP_NR(virt)  ((virt-PKMAP_BASE) >> PAGE_SHIFT)
 #define PKMAP_ADDR(nr)  (PKMAP_BASE + ((nr) << PAGE_SHIFT))
 
-#define KMAP_FIX_BEGIN	(0xfe400000UL)
 
 extern unsigned long kmap_high(struct page *page);
 extern void kunmap_high(struct page *page);

Re: HIGHMEM now working

[Paul Mackerras]

Tilmann Bitterberg writes:

> I saw that you recently did some fixes for HIGHMEM on CHRP, but
> they did not work. Actually, I can't get the kernel to boot on a

Where did you get the version you tried?  I recently got a kernel
going with highmem on a 44p/170 but I haven't pushed all the changes
into bk.  I had to make several changes to the python code as well as
arch/ppc/mm/init.c and my changes are somewhat different to what is
being done in the linuxppc_2_5 tree.  My changes are available in the
rsync tree at ppc.samba.org::linux-pmac-devel but that is
unfortunately almost unusable because of bandwidth restrictions on
that machine.  I am trying to get a ppc.linuxcare.com machine set up
in California but that is proving to be a slow process.

> Why not just lower PKMAP_BASE to 0xf6000000, will this break
> someone?

Everyone, potentially. :-)  You're lucky it worked.

The way the code is at the moment, we divide up the space between the
end of RAM and the end of the address space (0xffffffff) like this:

    end of RAM ... end of RAM + VMALLOC_OFFSET:	    not used
    end of RAM + VMALLOC_OFFSET ... ioremap_bot:    vmalloc & ioremap
    ioremap_bot ... ioremap_base:		    early ioremaps
    ioremap_base ... 0xffffffff:		    ioremap virt = phys

In other words all of the address space from end of RAM +
VMALLOC_OFFSET is potentially used by ioremap (which is a bit greedy
of it really).  I personally think that the code in ioremap which
assigns virt = phys for phys >= ioremap_base should go away.  For now
I have added an extra check in the highmem case so that it only uses
virt = phys for ioremap_base <= phys <= PKMAP_BASE.  This shows up one
or two missing ioremaps in the chrp code which I have fixed in my
version.

Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Dan Malek]

Paul Mackerras wrote:

> ....  I personally think that the code in ioremap which
> assigns virt = phys for phys >= ioremap_base should go away.

Right, but that is just the most recent implementation for something
we have to admit exists and we integrate into your HIGHMEM and other
changes.  We have to allow, somehow, mapping of board control registers
or other resources that must be used prior to page tables or other
VM initialization.  Right now we map things in BATs or large TLB
entries and then use the code above (or some other variation) to
ensure the mapping sticks throughout the kernel lifetime.  I don't
think it has to be virt == phys (which is just convenient for assembly
set up), but the mapping has to remain consistent even after the kernel
VM has been initialized.  The reason virt == phys is convenient is
because we often access this space with and without the MMU enabled.
We would have to add some code in the places this is done to further
convert addresses, when right now we just write the functions without
any MMU assumptions.


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Paul Mackerras]

Dan Malek writes:

> Right, but that is just the most recent implementation for something
> we have to admit exists and we integrate into your HIGHMEM and other
> changes.  We have to allow, somehow, mapping of board control registers
> or other resources that must be used prior to page tables or other
> VM initialization.  Right now we map things in BATs or large TLB

OK, that means you need to access these things in the bootloader, or
inside identify_machine() (which calls m8xx_init in your case) or
MMU_init().  Once we get into setup_arch (and then m8xx_setup_arch) we
can just ioremap as normal.

What do you have to initialize that can't wait until m8xx_setup_arch?
Can you give me an example of what sorts of physical addresses you
need to access?

Thanks,
Paul.

--
Paul Mackerras, Senior Open Source Researcher, Linuxcare, Inc.
+61 2 6262 8990 tel, +61 2 6262 8991 fax
paulus@linuxcare.com.au, http://www.linuxcare.com.au/
Linuxcare.  Support for the revolution.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Dan Malek]

Paul Mackerras wrote:

> What do you have to initialize that can't wait until m8xx_setup_arch?

I set up the 8xx/82xx CPM.  I can cheat here and grab some physical
pages of memory before the VM grabs them and makes me jump through
hoops to get pages I can just __pa() or __va() :-).  I could probably
move this to later.  I also use a #define IMMR for a pointer to the
internal space of the processor.  Saves a few cycles, but I should
really make this a variable.  I can use the #define because I know
the VM mapping is going to be 1:1.

It's nothing I can't change......


	-- Dan

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Wolfgang Denk]

In message <39ED3EF5.FF4D52E6@mvista.com> Dan Malek wrote:
>
> move this to later.  I also use a #define IMMR for a pointer to the
> internal space of the processor.  Saves a few cycles, but I should
> really make this a variable.  I can use the #define because I know

What do you think about including IMMR in the board  info  structure,
and  using  this?  That's  what we're doing for PPCBoot systems (that
don't use/need a special boot loader).

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Conceptual integrity in turn dictates that the  design  must  proceed
from  one  mind,  or  from  a  very small number of agreeing resonant
minds.               - Frederick Brooks Jr., "The Mythical Man Month"

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Dan Malek]

Wolfgang Denk wrote:

> What do you think about including IMMR in the board  info  structure,

That is a good idea.  I started doing that on the 8260s because you
can't find the IMMR in any special register.  Next, I am going to change
all of the ((immr_t *)IMMR)-> to use a global immr variable.  Then I
am going to remove the IMMR TLB entry, finish the support for large,
wired TLB entries, and have this initialized as part of the m8xx set up.


	-- Dan

--

	I like MMUs because I don't have a real life.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: HIGHMEM now working

[Tilmann Bitterberg]

On Tue, 17 Oct 2000, Paul Mackerras wrote:

> Where did you get the version you tried?  I recently got a kernel
> going with highmem on a 44p/170 but I haven't pushed all the changes
> into bk.  I had to make several changes to the python code as well as
> arch/ppc/mm/init.c and my changes are somewhat different to what is
> being done in the linuxppc_2_5 tree.  My changes are available in the
> rsync tree at ppc.samba.org::linux-pmac-devel but that is

I tried test10-pre2 with the bitkeeper patch yesterday. Now I
upgraded to test0-pre3 with the bitkeeper patch. Both kernels
are only working (without HIGHMEM) when I revert the setbat
setting back to its original behaviour (0xf8000000-0xffffffff).
I understand what you did, but its not working right now.

> > Why not just lower PKMAP_BASE to 0xf6000000, will this break
> > someone?
>
> Everyone, potentially. :-)  You're lucky it worked.
>
> The way the code is at the moment, we divide up the space between the
> end of RAM and the end of the address space (0xffffffff) like this:
>
>     end of RAM ... end of RAM + VMALLOC_OFFSET:	    not used
>     end of RAM + VMALLOC_OFFSET ... ioremap_bot:    vmalloc & ioremap
>     ioremap_bot ... ioremap_base:		    early ioremaps
>     ioremap_base ... 0xffffffff:		    ioremap virt = phys

I know, that I take space away from the VMMALLOC area. But is
this a Bad Thing(TM)?

So my map look like this:
     end of RAM + VMALLOC_OFFSET ... Highmem start (0xf6000000)
     Highmem end (0xf8000000) ... ioremap_bot
     ioremap_bot ... ioremap_base
     ioremap_base (0xf8000000) ... 0xfffffffff virt=phys with BAT

> In other words all of the address space from end of RAM +
> VMALLOC_OFFSET is potentially used by ioremap (which is a bit greedy
> of it really).

OK, now I see.

> I personally think that the code in ioremap which assigns virt
> = phys for phys >= ioremap_base should go away.  For now I
> have added an extra check in the highmem case so that it only
> uses virt = phys for ioremap_base <= phys <= PKMAP_BASE.  This
> shows up one or two missing ioremaps in the chrp code which I
> have fixed in my version.

I don't like the virt=phys mapping, but it seems some drivers
depend on that.

I'll try to rsync and see if I can merge the python changes into
my stuff.

Thanks
Tilmann


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/