* Re: [PATCH to v2.6.33] sh: Fix cannot booting zImage using CONFIG_PMB_FIXED
2010-02-15 8:37 [PATCH to v2.6.33] sh: Fix cannot booting zImage using Nobuhiro Iwamatsu
@ 2010-02-16 1:38 ` Paul Mundt
2010-03-03 6:19 ` [PATCH to v2.6.33] sh: Fix cannot booting zImage using Nobuhiro Iwamatsu
1 sibling, 0 replies; 3+ messages in thread
From: Paul Mundt @ 2010-02-16 1:38 UTC (permalink / raw)
To: linux-sh
On Mon, Feb 15, 2010 at 05:37:50PM +0900, Nobuhiro Iwamatsu wrote:
> diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
> index d509a50..5ff6dfc 100644
> --- a/arch/sh/boot/compressed/misc.c
> +++ b/arch/sh/boot/compressed/misc.c
> @@ -117,7 +117,7 @@ void decompress_kernel(void)
> output_addr = (CONFIG_MEMORY_START + 0x2000);
> #else
> output_addr = __pa((unsigned long)&_text+PAGE_SIZE);
> -#ifdef CONFIG_29BIT
> +#if defined(CONFIG_29BIT) || defined(CONFIG_PMB_FIXED)
> output_addr |= P2SEG;
> #endif
> #endif
This isn't technically a regresion, since it obviously never worked
before either. While we could do this for 2.6.33, things have already
changed quite a bit for 2.6.34, and ideally we will have ripped out the
fixed PMB mess entirely by 2.6.35. In light of its pending demise I'm
not terribly inclined to merge stop-gap patches for single kernel
versions.
Now, regarding fixed PMB.. The biggest issue with this scheme at the
moment is that the boot loader sets up absurd mappings and wastes
almost all of the PMB space in the process, as well as forcing P2 on us,
none of which are things we want. The differences we have to contend with
are the differing entry points, where we do the vmsplit, and where the
uncached mapping is placed. Now that the uncached mapping is constructed
following the cached one and simply maps a single page for kernel text we
end up getting quite a bit of our address space back, even if it's only
usable by the PMB. The entry point variations we still have to contend
with, but we can abstract that more cleanly, and other non-PMB parts have
a vested interest there as well. Variable vmsplit work is on-going, so
that should be something else that pops up in the not so distant future.
Initially I had considered tolerating the existence of fixed PMB mode,
but the boot loader as usual doesn't seem to do anything of merit with
the leeway that it's given, so the best course of action will simply be
to blow away whatever the boot loader has done and have the kernel manage
all of the mappings. We already have the transitioning logic in place, so
with a bit of work we should be able to throw out the fixed PMB stuff
entirely. Even on platforms that aren't going to use sparsemem vmemmap,
the larger PCI windows mean we're going to be using up more vmalloc
space, which we can at least pad a bit by stuffing spare P2 space in to a
PMB-backed VMA to fix up transparent PMB use through ioremap(), which
otherwise is virtual address space that the TLB can't touch.
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: [PATCH to v2.6.33] sh: Fix cannot booting zImage using
2010-02-15 8:37 [PATCH to v2.6.33] sh: Fix cannot booting zImage using Nobuhiro Iwamatsu
2010-02-16 1:38 ` [PATCH to v2.6.33] sh: Fix cannot booting zImage using CONFIG_PMB_FIXED Paul Mundt
@ 2010-03-03 6:19 ` Nobuhiro Iwamatsu
1 sibling, 0 replies; 3+ messages in thread
From: Nobuhiro Iwamatsu @ 2010-03-03 6:19 UTC (permalink / raw)
To: linux-sh
Hi , Paul.
I'm sorry for this late reply.
2010/2/16 Paul Mundt <lethal@linux-sh.org>:
> On Mon, Feb 15, 2010 at 05:37:50PM +0900, Nobuhiro Iwamatsu wrote:
>> diff --git a/arch/sh/boot/compressed/misc.c b/arch/sh/boot/compressed/misc.c
>> index d509a50..5ff6dfc 100644
>> --- a/arch/sh/boot/compressed/misc.c
>> +++ b/arch/sh/boot/compressed/misc.c
>> @@ -117,7 +117,7 @@ void decompress_kernel(void)
>> output_addr = (CONFIG_MEMORY_START + 0x2000);
>> #else
>> output_addr = __pa((unsigned long)&_text+PAGE_SIZE);
>> -#ifdef CONFIG_29BIT
>> +#if defined(CONFIG_29BIT) || defined(CONFIG_PMB_FIXED)
>> output_addr |= P2SEG;
>> #endif
>> #endif
>
> This isn't technically a regresion, since it obviously never worked
> before either. While we could do this for 2.6.33, things have already
> changed quite a bit for 2.6.34, and ideally we will have ripped out the
> fixed PMB mess entirely by 2.6.35. In light of its pending demise I'm
> not terribly inclined to merge stop-gap patches for single kernel
> versions.
I did wrong understanding.
I understood your point.
>
> Now, regarding fixed PMB.. The biggest issue with this scheme at the
> moment is that the boot loader sets up absurd mappings and wastes
> almost all of the PMB space in the process, as well as forcing P2 on us,
> none of which are things we want. The differences we have to contend with
> are the differing entry points, where we do the vmsplit, and where the
> uncached mapping is placed. Now that the uncached mapping is constructed
> following the cached one and simply maps a single page for kernel text we
> end up getting quite a bit of our address space back, even if it's only
> usable by the PMB. The entry point variations we still have to contend
> with, but we can abstract that more cleanly, and other non-PMB parts have
> a vested interest there as well. Variable vmsplit work is on-going, so
> that should be something else that pops up in the not so distant future.
>
> Initially I had considered tolerating the existence of fixed PMB mode,
> but the boot loader as usual doesn't seem to do anything of merit with
> the leeway that it's given, so the best course of action will simply be
> to blow away whatever the boot loader has done and have the kernel manage
> all of the mappings. We already have the transitioning logic in place, so
> with a bit of work we should be able to throw out the fixed PMB stuff
> entirely. Even on platforms that aren't going to use sparsemem vmemmap,
> the larger PCI windows mean we're going to be using up more vmalloc
> space, which we can at least pad a bit by stuffing spare P2 space in to a
> PMB-backed VMA to fix up transparent PMB use through ioremap(), which
> otherwise is virtual address space that the TLB can't touch.
I see.
Best regards,
Nobuhiro
--
Nobuhiro Iwamatsu
iwamatsu at {nigauri.org / debian.org}
GPG ID: 40AD1FA6
^ permalink raw reply [flat|nested] 3+ messages in thread