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
From: Paul Mackerras <hidden> Date: 2000-10-17 04:52:41
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/
From: Dan Malek <hidden> Date: 2000-10-17 05:17:27
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/
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.
quoted
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/
From: Paul Mackerras <hidden> Date: 2000-10-18 05:36:47
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/
From: Dan Malek <hidden> Date: 2000-10-18 06:11:01
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/