[PATCH] alpha: fix ALPHA_LEGACY_START_ADDRESS and default to no

[PATCH] alpha: fix ALPHA_LEGACY_START_ADDRESS and default to no

[Matt Turner]

[-- Attachment #1: Type: text/plain, Size: 1865 bytes --]

Kconfig.debug had ALPHA_LEGACY_START_ADDRESS twice, which seemed to mess
the whole thing up so that the only way that you could unselect
it was to set ALPHA_GENERIC. That is to say, setting ALPHA_TITAN
actually prevented unsetting ALPHA_LEGACY_START_ADDRESS, which is
necessary for Titan systems. WTF.

Also, in my two and a half years of doing alpha stuff, I've only known
one person to use MILO and this was on a 164UX where he had no option,
and the kernel has been broken on this board since 2.6.23 anyway. So,
even with as few Marvel/Titan systems as there are, there are fewer MILO
users.

This does mean that people who use MILO (do you still exist?) will have
to make sure to set this option. If you're using <aboot-0.7 then I have
no sympathy for you.

Signed-off-by: Matt Turner <mattst88@gmail.com>
---
 arch/alpha/Kconfig.debug |    7 +------
 1 files changed, 1 insertions(+), 6 deletions(-)

diff --git a/arch/alpha/Kconfig.debug b/arch/alpha/Kconfig.debug
index 3f6265f..b2589b2 100644
--- a/arch/alpha/Kconfig.debug
+++ b/arch/alpha/Kconfig.debug
@@ -9,7 +9,7 @@ config EARLY_PRINTK
 
 config ALPHA_LEGACY_START_ADDRESS
 	bool "Legacy kernel start address"
-	depends on ALPHA_GENERIC
+	depends on !ALPHA_GENERIC && !ALPHA_TITAN && !ALPHA_MARVEL && !ALPHA_WILDFIRE
 	default n
 	---help---
 	  The 2.4 kernel changed the kernel start address from 0x310000
@@ -26,11 +26,6 @@ config ALPHA_LEGACY_START_ADDRESS
 	  Say Y if you have a broken bootloader.  Say N if you do not, or if
 	  you wish to run on Wildfire, Titan, or Marvel.
 
-config ALPHA_LEGACY_START_ADDRESS
-	bool
-	depends on !ALPHA_GENERIC && !ALPHA_TITAN && !ALPHA_MARVEL && !ALPHA_WILDFIRE
-	default y
-
 config MATHEMU
 	tristate "Kernel FP software completion" if DEBUG_KERNEL && !SMP
 	default y if !DEBUG_KERNEL || SMP
-- 
1.7.2.2


[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]

Re: [PATCH] alpha: fix ALPHA_LEGACY_START_ADDRESS and default to no

[Kaj-Michael Lang]

On Fri, 29 Oct 2010, Matt Turner wrote:

> Also, in my two and a half years of doing alpha stuff, I've only known
> one person to use MILO and this was on a 164UX where he had no option,
> This does mean that people who use MILO (do you still exist?) will have

+1 yes we do exist.
My aspen can only use (and an old one at that) MILO as changing to SRM 
requires swapping the ROM chips. And my 164LX uses MILO too.

Re: [PATCH] alpha: fix ALPHA_LEGACY_START_ADDRESS and default to no

[Michael Cree]

On 29/10/10 17:22, Matt Turner wrote:
> Kconfig.debug had ALPHA_LEGACY_START_ADDRESS twice, which seemed to mess
> the whole thing up so that the only way that you could unselect
> it was to set ALPHA_GENERIC. That is to say, setting ALPHA_TITAN
> actually prevented unsetting ALPHA_LEGACY_START_ADDRESS, which is
> necessary for Titan systems. WTF.

I don't see what the problem is that you are trying to fix.  The current 
Kconfig is set up to automatically turn on ALPHA_LEGACY_START_ADDRESS if 
you select a specific Alpha system for which it is safe to use 
ALPHA_LEGACY_START_ADDRESS and will automatically turn it off if you 
select one of Titan, Marvel or Wildfire.  If you select a Generic system 
then Kconfig enables the ALPHA_LEGACY_START_ADDRESS under the Kernel 
hacking menu so that it can be manually decided whether it should be on 
or off.

Debian, for example, uses this to build two different generic kernels, 
one with the legacy start address and one without.  Users can choose 
which kernel to use at install time.

If I turn on Titan in the config, then the Legacy Start Address menu 
item disappears, and the .config file is generated with 
ALPHA_LEGACY_START_ADDRESS off.  This appears to me to be the correct 
behaviour.

Cheers
Michael.

Re: [PATCH] alpha: fix ALPHA_LEGACY_START_ADDRESS and default to no

[Matt Turner]

On Fri, Oct 29, 2010 at 6:25 AM, Michael Cree <mcree@orcon.net.nz> wrote:
> On 29/10/10 17:22, Matt Turner wrote:
>>
>> Kconfig.debug had ALPHA_LEGACY_START_ADDRESS twice, which seemed to mess
>> the whole thing up so that the only way that you could unselect
>> it was to set ALPHA_GENERIC. That is to say, setting ALPHA_TITAN
>> actually prevented unsetting ALPHA_LEGACY_START_ADDRESS, which is
>> necessary for Titan systems. WTF.
>
> I don't see what the problem is that you are trying to fix.  The current
> Kconfig is set up to automatically turn on ALPHA_LEGACY_START_ADDRESS if you
> select a specific Alpha system for which it is safe to use
> ALPHA_LEGACY_START_ADDRESS and will automatically turn it off if you select
> one of Titan, Marvel or Wildfire.  If you select a Generic system then
> Kconfig enables the ALPHA_LEGACY_START_ADDRESS under the Kernel hacking menu
> so that it can be manually decided whether it should be on or off.
>
> Debian, for example, uses this to build two different generic kernels, one
> with the legacy start address and one without.  Users can choose which
> kernel to use at install time.
>
> If I turn on Titan in the config, then the Legacy Start Address menu item
> disappears, and the .config file is generated with
> ALPHA_LEGACY_START_ADDRESS off.  This appears to me to be the correct
> behaviour.
>
> Cheers
> Michael.

This has been on my todo list for so long that I forgot myself. Turns
out we had trouble building a kernel with LEGACY_START_ADDRESS=n, but
you fixed those errors in commit 3e073367a and I didn't make any
connection.

Does anyone know why ALPHA_LEGACY_START_ADDRESS is in Kconfig twice?
Is this a standard idiom that I don't know about?

I guess there's on point in unsetting this on systems that don't need
it? Does moving the kernel start address back on these systems 5MB
just remove their ability to use that memory?

So, ignore the patch.
Matt
--
To unsubscribe from this list: send the line "unsubscribe linux-alpha" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html