1. 20 3月, 2014 1 次提交
    • V
      x86, boot: Create a separate string.h file to provide standard string functions · c041b5ad
      Vivek Goyal 提交于
      Create a separate arch/x86/boot/string.h file to provide declaration of
      some of the common string functions.
      
      By default memcpy, memset and memcmp functions will default to gcc
      builtin functions. If code wants to use an optimized version of any
      of these functions, they need to #undef the respective macro and link
      against a local file providing definition of undefed function.
      
      For example, arch/x86/boot/* code links against copy.S to get memcpy()
      and memcmp() definitions. arch/86/boot/compressed/* links against
      compressed/string.c.
      
      There are quite a few places in arch/x86/ where these functions are
      used. Idea is to try to consilidate  their declaration and possibly
      definitions so that it can be reused.
      
      I am planning to reuse boot/string.h in arch/x86/purgatory/ and use
      gcc builtin functions for memcpy, memset and memcmp.
      Signed-off-by: NVivek Goyal <vgoyal@redhat.com>
      Link: http://lkml.kernel.org/r/1395170800-11059-3-git-send-email-vgoyal@redhat.comSigned-off-by: NH. Peter Anvin <hpa@linux.intel.com>
      c041b5ad
  2. 09 5月, 2012 1 次提交
  3. 03 8月, 2010 1 次提交
    • Y
      x86, setup: enable early console output from the decompressor · 8fee13a4
      Yinghai Lu 提交于
      This enables the decompressor output to be seen on the serial console.
      Most of the code is shared with the regular boot code.
      
      We could add printf to the decompressor if needed, but currently there
      is no sufficiently compelling user.
      
      -v2: define BOOT_BOOT_H to avoid include boot.h
      -v3: early_serial_base need to be static in misc.c ?
      -v4: create seperate string.c printf.c cmdline.c early_serial_console.c
           after hpa's patch that allow global variables in compressed/misc stage
      -v5: remove printf.c related
      Signed-off-by: NYinghai Lu <yinghai@kernel.org>
      Signed-off-by: NH. Peter Anvin <hpa@zytor.com>
      8fee13a4
  4. 13 7月, 2010 1 次提交
  5. 10 4月, 2009 1 次提交
  6. 23 2月, 2009 1 次提交
    • I
      x86: remove the Voyager 32-bit subarch · 965c7eca
      Ingo Molnar 提交于
      Impact: remove unused/broken code
      
      The Voyager subarch last built successfully on the v2.6.26 kernel
      and has been stale since then and does not build on the v2.6.27,
      v2.6.28 and v2.6.29-rc5 kernels.
      
      No actual users beyond the maintainer reported this breakage.
      Patches were sent and most of the fixes were accepted but the
      discussion around how to do a few remaining issues cleanly
      fizzled out with no resolution and the code remained broken.
      
      In the v2.6.30 x86 tree development cycle 32-bit subarch support
      has been reworked and removed - and the Voyager code, beyond the
      build problems already known, needs serious and significant
      changes and probably a rewrite to support it.
      
      CONFIG_X86_VOYAGER has been marked BROKEN then. The maintainer has
      been notified but no patches have been sent so far to fix it.
      
      While all other subarchs have been converted to the new scheme,
      voyager is still broken. We'd prefer to receive patches which
      clean up the current situation in a constructive way, but even in
      case of removal there is no obstacle to add that support back
      after the issues have been sorted out in a mutually acceptable
      fashion.
      
      So remove this inactive code for now.
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      965c7eca
  7. 14 8月, 2008 1 次提交
  8. 13 8月, 2008 1 次提交
    • J
      x86: fix setup code crashes on my old 486 box · 7b27718b
      Joerg Roedel 提交于
      yesterday I tried to reactivate my old 486 box and wanted to install a
      current Linux with latest kernel on it. But it turned out that the
      latest kernel does not boot because the machine crashes early in the
      setup code.
      
      After some debugging it turned out that the problem is the query_ist()
      function. If this interrupt with that function is called the machine
      simply locks up. It looks like a BIOS bug. Looking for a workaround for
      this problem I wrote the attached patch. It checks for the CPUID
      instruction and if it is not implemented it does not call the speedstep
      BIOS function. As far as I know speedstep should be available since some
      Pentium earliest.
      
      Alan Cox observed that it's available since the Pentium II, so cpuid
      levels 4 and 5 can be excluded altogether.
      
      H. Peter Anvin cleaned up the code some more:
      
      > Right in concept, but I dislike the implementation (duplication of the
      > CPU detect code we already have).  Could you try this patch and see if
      > it works for you?
      
      which, with a small modification to fix a build error with it the
      resulting kernel boots on my machine.
      Signed-off-by: NJoerg Roedel <joro@8bytes.org>
      Signed-off-by: N"H. Peter Anvin" <hpa@zytor.com>
      Cc: <stable@kernel.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7b27718b
  9. 31 5月, 2008 1 次提交
  10. 20 4月, 2008 1 次提交
  11. 30 1月, 2008 2 次提交
  12. 24 10月, 2007 1 次提交
  13. 11 10月, 2007 1 次提交
  14. 26 7月, 2007 1 次提交
  15. 13 7月, 2007 1 次提交