[lkml]   [2009]   [May]   [8]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: [PATCH 03/14] x86, config: change defaults PHYSICAL_START and PHYSICAL_ALIGN
    Sam Ravnborg wrote:
    >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    >> index 039c3f0..13b3a5a 100644
    >> --- a/arch/x86/Kconfig
    >> +++ b/arch/x86/Kconfig
    >> @@ -1455,17 +1455,20 @@ config KEXEC_JUMP
    >> config PHYSICAL_START
    >> hex "Physical address where the kernel is loaded" if (EMBEDDED || CRASH_DUMP)
    >> - default "0x1000000" if X86_NUMAQ
    >> - default "0x200000" if X86_64
    >> - default "0x100000"
    >> + default "0x400000" if EMBEDDED
    >> + default "0x1000000"
    >> ---help---
    >> This gives the physical address where the kernel is loaded.
    >> If kernel is a not relocatable (CONFIG_RELOCATABLE=n) then
    >> bzImage will decompress itself to above physical address and
    >> - run from there. Otherwise, bzImage will run from the address where
    >> - it has been loaded by the boot loader and will ignore above physical
    >> - address.
    >> + run from there. Otherwise, bzImage will run from the either
    >> + the above physical address or where it has been loaded by
    >> + the boot loader, whichever is higher.
    >> +
    >> + For embedded machines with very small memory (less than
    >> + about 24 MB) this may need to be adjusted downward from the
    >> + default value of 0x1000000 (16 MB).
    > But in the above you say that default is "0x400000" if EMBEDDED
    > That is in contradiction with the help - no?

    0x1000000 really should be the default value. The "0x400000" if
    EMBEDDED I put in to make the risk of throwing something surprising on
    embedded people somewhat smaller; I'm not sure if it should go away
    entirely. Even if it doesn't, I do think referring to 16 MB as the
    "default value" is right.

    BTW, it would be nice to have Kconfig deal with:

    a) numbers that must be powers of 2;
    b) suffixes like "16M" instead of "0x1000000". ;)


    H. Peter Anvin, Intel Open Source Technology Center
    I work for Intel. I don't speak on their behalf.

     \ /
      Last update: 2009-05-08 19:07    [W:0.027 / U:10.784 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site