2.6.25-mm1 - Kernel

This is a discussion on 2.6.25-mm1 - Kernel ; On Fri, 18 Apr 2008 20:29:25 -0700 Andrew Morton wrote: > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote: > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote: > > > > > ...

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast
Results 21 to 40 of 105

Thread: 2.6.25-mm1

  1. Re: 2.6.25-mm1

    On Fri, 18 Apr 2008 20:29:25 -0700
    Andrew Morton wrote:

    > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote:
    >
    > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
    > > >
    > > > ftp://ftp.kernel.org/pub/linux/kerne...25/2.6.25-mm1/

    > >
    > > New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
    > >
    > > "[ 0.160375] NET: Registered protocol family 16"
    > >
    > > The hang lasts about five minutes, and then boot continues.

    >
    > Please add initcall_debug to the kernel boot command line - that should
    > narrow it down.
    >
    > > Just
    > > after that, a backtrace is printed; I don't know if it's related. The
    > > backtrace will follow.
    > >
    > > This does not occur in mainline. It seems it might be related to OLPC
    > > support -- I enabled all those options -- but that's not good
    > > behavior, and I see no warning of thus in the help.
    > >
    > > I'm sending a number or reports against 2.6.25-mm1, so I've put my
    > > dmesg and .config on a server:
    > >
    > > http://home.columbus.rr.com/jfannin3/dmesg.txt
    > > http://home.columbus.rr.com/jfannin3...2.6.25-mm1.txt
    > >
    > > [ 0.160375] NET: Registered protocol family 16
    > > [ 400.782683] ------------[ cut here ]------------
    > > [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
    > > [ 400.783022] Modules linked in:
    > > [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
    > > [ 400.783300] [] warn_on_slowpath+0x59/0x80
    > > [ 400.783480] [] ? profile_pc+0x3e/0x50
    > > [ 400.783682] [] ? irq_exit+0x4e/0xa0
    > > [ 400.783879] [] ? smp_apic_timer_interrupt+0x5c/0x90
    > > [ 400.784087] [] ? trace_hardirqs_on_thunk+0xc/0x10
    > > [ 400.784298] [] ? trace_hardirqs_on_caller+0xcd/0x150
    > > [ 400.784506] [] ? trace_hardirqs_on_thunk+0xc/0x10
    > > [ 400.784706] [] ? restore_nocheck_notrace+0x0/0xe
    > > [ 400.784906] [] ? page_is_ram+0xa6/0xd0
    > > [ 400.785059] [] __ioremap_caller+0x27d/0x2e0
    > > [ 400.785221] [] ? _spin_unlock_irqrestore+0x48/0x80
    > > [ 400.785421] [] ? ftrace_record_ip+0x7d/0x250
    > > [ 400.785621] [] ? olpc_init+0x31/0x140
    > > [ 400.785817] [] ioremap_nocache+0x1f/0x30
    > > [ 400.785976] [] ? olpc_init+0x31/0x140
    > > [ 400.786165] [] olpc_init+0x31/0x140
    > > [ 400.786318] [] kernel_init+0x142/0x2d0
    > > [ 400.786479] [] ? trace_hardirqs_on_caller+0xcd/0x150
    > > [ 400.786680] [] ? restore_nocheck_notrace+0x0/0xe
    > > [ 400.786879] [] ? kernel_init+0x0/0x2d0
    > > [ 400.787069] [] ? kernel_init+0x0/0x2d0
    > > [ 400.787260] [] kernel_thread_helper+0x7/0x10
    > > [ 400.787422] =======================
    > > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---

    >
    >
    >
    > That's
    >
    > WARN_ON_ONCE(is_ram);
    >
    > the changelog for the patch which added that warning is information-free
    > and there's no code comment explaining what went wrong, which makes things
    > rather harder than they ought to be.
    >
    > Yes it's due to the new OLPC code. olpc_init() has
    >
    > romsig = ioremap(0xffffffc0, 16);
    >
    > which we probably just shouldn't do this at all unless we're running on the
    > OLPC hardware. But we need to do this to find out if we're running on the OLPC
    > hardware! Perhaps the warning should just be removed.


    Hm. We could either protect that code with an:

    if (!is_geode())
    return;

    Or I could add the OpenFirmware patches which would allow us to get
    rid of this code, and instead check for the existence of OFW using
    that.

    The former is quick and easy; the latter is (imo) nicer, so long as
    people don't have problems w/ the OFW code.


    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  2. Re: 2.6.25-mm1

    > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon wrote:
    > On Fri, 18 Apr 2008 20:29:25 -0700
    > Andrew Morton wrote:
    >
    > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote:
    > >
    > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:
    > > > >
    > > > > ftp://ftp.kernel.org/pub/linux/kerne...25/2.6.25-mm1/
    > > >
    > > > New, in 2.6.25-mm1 is a hang I'm seeing, just after the kernel prints:
    > > >
    > > > "[ 0.160375] NET: Registered protocol family 16"
    > > >
    > > > The hang lasts about five minutes, and then boot continues.

    > >
    > > Please add initcall_debug to the kernel boot command line - that should
    > > narrow it down.
    > >
    > > > Just
    > > > after that, a backtrace is printed; I don't know if it's related. The
    > > > backtrace will follow.
    > > >
    > > > This does not occur in mainline. It seems it might be related to OLPC
    > > > support -- I enabled all those options -- but that's not good
    > > > behavior, and I see no warning of thus in the help.
    > > >
    > > > I'm sending a number or reports against 2.6.25-mm1, so I've put my
    > > > dmesg and .config on a server:
    > > >
    > > > http://home.columbus.rr.com/jfannin3/dmesg.txt
    > > > http://home.columbus.rr.com/jfannin3...2.6.25-mm1.txt
    > > >
    > > > [ 0.160375] NET: Registered protocol family 16
    > > > [ 400.782683] ------------[ cut here ]------------
    > > > [ 400.782832] WARNING: at arch/x86/mm/ioremap.c:158 __ioremap_caller+0x27d/0x2e0()
    > > > [ 400.783022] Modules linked in:
    > > > [ 400.783169] Pid: 1, comm: swapper Not tainted 2.6.25-mm1 #7
    > > > [ 400.783300] [] warn_on_slowpath+0x59/0x80
    > > > [ 400.783480] [] ? profile_pc+0x3e/0x50
    > > > [ 400.783682] [] ? irq_exit+0x4e/0xa0
    > > > [ 400.783879] [] ? smp_apic_timer_interrupt+0x5c/0x90
    > > > [ 400.784087] [] ? trace_hardirqs_on_thunk+0xc/0x10
    > > > [ 400.784298] [] ? trace_hardirqs_on_caller+0xcd/0x150
    > > > [ 400.784506] [] ? trace_hardirqs_on_thunk+0xc/0x10
    > > > [ 400.784706] [] ? restore_nocheck_notrace+0x0/0xe
    > > > [ 400.784906] [] ? page_is_ram+0xa6/0xd0
    > > > [ 400.785059] [] __ioremap_caller+0x27d/0x2e0
    > > > [ 400.785221] [] ? _spin_unlock_irqrestore+0x48/0x80
    > > > [ 400.785421] [] ? ftrace_record_ip+0x7d/0x250
    > > > [ 400.785621] [] ? olpc_init+0x31/0x140
    > > > [ 400.785817] [] ioremap_nocache+0x1f/0x30
    > > > [ 400.785976] [] ? olpc_init+0x31/0x140
    > > > [ 400.786165] [] olpc_init+0x31/0x140
    > > > [ 400.786318] [] kernel_init+0x142/0x2d0
    > > > [ 400.786479] [] ? trace_hardirqs_on_caller+0xcd/0x150
    > > > [ 400.786680] [] ? restore_nocheck_notrace+0x0/0xe
    > > > [ 400.786879] [] ? kernel_init+0x0/0x2d0
    > > > [ 400.787069] [] ? kernel_init+0x0/0x2d0
    > > > [ 400.787260] [] kernel_thread_helper+0x7/0x10
    > > > [ 400.787422] =======================
    > > > [ 400.787727] ---[ end trace 4eaa2a86a8e2da22 ]---

    > >
    > >
    > >
    > > That's
    > >
    > > WARN_ON_ONCE(is_ram);
    > >
    > > the changelog for the patch which added that warning is information-free
    > > and there's no code comment explaining what went wrong, which makes things
    > > rather harder than they ought to be.
    > >
    > > Yes it's due to the new OLPC code. olpc_init() has
    > >
    > > romsig = ioremap(0xffffffc0, 16);
    > >
    > > which we probably just shouldn't do this at all unless we're running on the
    > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
    > > hardware! Perhaps the warning should just be removed.

    >
    > Hm. We could either protect that code with an:
    >
    > if (!is_geode())
    > return;
    >
    > Or I could add the OpenFirmware patches which would allow us to get
    > rid of this code, and instead check for the existence of OFW using
    > that.
    >
    > The former is quick and easy; the latter is (imo) nicer, so long as
    > people don't have problems w/ the OFW code.
    >


    Do both

    The quick-n-easy version sounds suitable for now.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  3. [PATCH 1/2] OLPC: Add support for calling into Open Firmware


    This adds 32-bit support for calling into OFW from the kernel. It's useful
    for querying the firmware for misc hardware information, fetching the device
    tree, etc.

    There's potentially no reason why other platforms couldn't use this, but
    currently OLPC is the main user of it.

    This work was originally done by Mitch Bradley.

    Signed-off-by: Andres Salomon
    ---
    arch/x86/Kconfig | 8 +++++
    arch/x86/kernel/Makefile | 1 +
    arch/x86/kernel/head_32.S | 27 ++++++++++++++++
    arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
    include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
    include/asm-x86/setup.h | 1 +
    6 files changed, 162 insertions(+), 0 deletions(-)
    create mode 100644 arch/x86/kernel/ofw.c
    create mode 100644 include/asm-x86/ofw.h

    diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    index 3b9089b..ce56105 100644
    --- a/arch/x86/Kconfig
    +++ b/arch/x86/Kconfig
    @@ -661,6 +661,14 @@ config I8K
    Say Y if you intend to run this kernel on a Dell Inspiron 8000.
    Say N otherwise.

    +config OPEN_FIRMWARE
    + bool "Support for Open Firmware"
    + default y if OLPC
    + ---help---
    + This option adds support for the implementation of Open Firmware
    + that is used on the OLPC XO laptop.
    + If unsure, say N here.
    +
    config X86_REBOOTFIXUPS
    def_bool n
    prompt "Enable X86 board specific fixups for reboot"
    diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
    index 9575754..d33600e 100644
    --- a/arch/x86/kernel/Makefile
    +++ b/arch/x86/kernel/Makefile
    @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
    obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
    obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
    obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
    +obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
    obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
    obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
    obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
    diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
    index 74d87ea..c9d2d00 100644
    --- a/arch/x86/kernel/head_32.S
    +++ b/arch/x86/kernel/head_32.S
    @@ -132,6 +132,33 @@ ENTRY(startup_32)
    movsl
    1:

    +#ifdef CONFIG_OPEN_FIRMWARE
    +/*
    + * If Open Firmware booted us, save the OFW client interface callback address
    + * and preserve the OFW page mappings by priming the kernel's new page
    + * directory area with a copy of the OFW page directory. That lets OFW stay
    + * resident in high memory (high in both the virtual and physical spaces)
    + * for at least long enough to copy out the device tree.
    + */
    + movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
    + cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
    + jne 4f
    +
    + mov 0x8(%ebp), %eax /* Save callback address */
    + mov %eax, pa(call_firmware)
    +
    + /* Copy the OFW pdir into swapper_pg_dir */
    + movl %esi, %edx /* save %esi */
    + movl $pa(swapper_pg_dir), %edi
    + movl %cr3, %esi /* Source is current pg_dir base address */
    + movl $1024, %ecx /* Number of page directory entries */
    + rep
    + movsl
    + movl %edx, %esi /* restore %esi */
    +4:
    +
    +#endif
    +
    #ifdef CONFIG_PARAVIRT
    /* This is can only trip for a broken bootloader... */
    cmpw $0x207, pa(boot_params + BP_version)
    diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
    new file mode 100644
    index 0000000..14036aa
    --- /dev/null
    +++ b/arch/x86/kernel/ofw.c
    @@ -0,0 +1,75 @@
    +/*
    + * Open Firmware client interface for 32-bit systems.
    + *
    + * Copyright © 2007 Mitch Bradley
    + * Copyright © 2007-2008 Andres Salomon
    + *
    + * This program is free software; you can redistribute it and/or modify
    + * it under the terms of the GNU General Public License as published by
    + * the Free Software Foundation; either version 2 of the License, or
    + * (at your option) any later version.
    + */
    +
    +#include
    +#include
    +#include
    +#include
    +
    +/*
    + * This code is intended to be portable to any 32-bit Open Firmware
    + * implementation with a standard client interface that can be
    + * called when Linux is running.
    + *
    + * The return value from ofw() in all cases is 0 if the attempt to call the
    + * function succeeded. The return value is from the Linux function only; any
    + * results from OFW are returned via output argument pointers.
    + */
    +
    +#define MAXARGS 20
    +
    +int (*call_firmware)(int *);
    +static DEFINE_SPINLOCK(prom_lock);
    +
    +int ofw(const char *name, int nr_args, int nr_results, ...)
    +{
    + unsigned long flags;
    + va_list args;
    + int argarray[MAXARGS+3];
    + int retval;
    + int *intp;
    + int i;
    +
    + if (!call_firmware)
    + return -ENODEV;
    +
    + if ((nr_args + nr_results) > MAXARGS)
    + return -EIO; /* spit out an error? */
    +
    + /* Stuff the arguments into argarray */
    + argarray[0] = (int) name;
    + argarray[1] = nr_args;
    + argarray[2] = nr_results;
    +
    + va_start(args, nr_results);
    + for (i = 3; nr_args; i++) {
    + argarray[i] = va_arg(args, int);
    + nr_args--;
    + }
    +
    + /* Call into Open Firmware */
    + spin_lock_irqsave(&prom_lock, flags);
    + retval = call_firmware(argarray);
    + spin_unlock_irqrestore(&prom_lock, flags);
    +
    + if (retval == 0) {
    + while (nr_results) {
    + intp = va_arg(args, int *);
    + *intp = argarray[i++];
    + nr_results--;
    + }
    + }
    +
    + va_end(args);
    + return retval;
    +}
    +EXPORT_SYMBOL_GPL(ofw);
    diff --git a/include/asm-x86/ofw.h b/include/asm-x86/ofw.h
    new file mode 100644
    index 0000000..7d064f8
    --- /dev/null
    +++ b/include/asm-x86/ofw.h
    @@ -0,0 +1,50 @@
    +/*
    + * Definitions for Open Firmware client interface on 32-bit system.
    + * OF Cell size is 4. Integer properties are encoded big endian,
    + * as with all OF implementations.
    + */
    +#ifndef _OFW_H
    +#define _OFW_H
    +#ifdef __KERNEL__
    +
    +extern int ofw(const char *name, int nr_args, int nr_results, ...);
    +
    +typedef uint32_t ofw_phandle;
    +typedef uint32_t ofw_ihandle;
    +
    +/*
    + * Here are call templates for standard OFW client services:
    + *
    + * ofw("test", 1, 1, namestr, &missing);
    + * ofw("peer", 1, 1, phandle, &sibling_phandle);
    + * ofw("child", 1, 1, phandle, &child_phandle);
    + * ofw("parent", 1, 1, phandle, &parent_phandle);
    + * ofw("instance_to_package", 1, 1, ihandle, &phandle);
    + * ofw("getproplen", 2, 1, phandle, namestr, &proplen);
    + * ofw("getprop", 4, 1, phandle, namestr, bufaddr, buflen, &size);
    + * ofw("nextprop", 3, 1, phandle, previousstr, bufaddr, &flag);
    + * ofw("setprop", 4, 1, phandle, namestr, bufaddr, len, &size);
    + * ofw("canon", 3, 1, devspecstr, bufaddr, buflen, &length);
    + * ofw("finddevice", 1, 1, devspecstr, &phandle);
    + * ofw("instance-to-path", 3, 1, ihandle, bufaddr, buflen, &length);
    + * ofw("package-to-path", 3, 1, phandle, bufaddr, buflen, &length);
    + * ofw("call_method", numin, numout, in0, in1, ..., &out0, &out1, ...);
    + * ofw("open", 1, 1, devspecstr, &ihandle);
    + * ofw("close", 1, 0, ihandle);
    + * ofw("read", 3, 1, ihandle, addr, len, &actual);
    + * ofw("write", 3, 1, ihandle, addr, len, &actual);
    + * ofw("seek", 3, 1, ihandle, pos_hi, pos_lo, &status);
    + * ofw("claim", 3, 1, virtaddr, size, align, &baseaddr);
    + * ofw("release", 2, 0, virtaddr, size);
    + * ofw("boot", 1, 0, bootspecstr);
    + * ofw("enter", 0, 0);
    + * ofw("exit", 0, 0);
    + * ofw("chain", 5, 0, virtaddr, size, entryaddr, argsaddr, len);
    + * ofw("interpret", numin+1, numout+1, cmdstr, in0, ..., &catchres, &out0, ...)
    + * ofw("set-callback", 1, 1, newfuncaddr, &oldfuncaddr);
    + * ofw("set-symbol-lookup", 2, 0, symtovaladdr, valtosymaddr);
    + * ofw("milliseconds", 0, 1, &ms);
    + */
    +
    +#endif
    +#endif
    diff --git a/include/asm-x86/setup.h b/include/asm-x86/setup.h
    index 071e054..8e2b674 100644
    --- a/include/asm-x86/setup.h
    +++ b/include/asm-x86/setup.h
    @@ -28,6 +28,7 @@ char *machine_specific_memory_setup(void);
    #define OLD_CL_MAGIC 0xA33F
    #define OLD_CL_ADDRESS 0x020 /* Relative to real mode data */
    #define NEW_CL_POINTER 0x228 /* Relative to real mode data */
    +#define OFW_INFO_OFFSET 0xb0 /* Relative to real mode data */

    #ifndef __ASSEMBLY__
    #include
    --
    1.5.4.4


    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  4. [PATCH 2/2] OLPC: drop pre-OpenFirmware workarounds


    Prior to including OFW kernel support, we had to work around the lack of
    OFW. Once OFW support is added, we can switch to using it. This cleans
    up some pre-OFW model detection and OFW signature detection.

    Note: this should be a bit nicer to non-OLPC hardware.

    Signed-off-by: Andres Salomon
    ---
    arch/x86/kernel/olpc.c | 43 +++++++++++++++++++++++++++++--------------
    1 files changed, 29 insertions(+), 14 deletions(-)

    diff --git a/arch/x86/kernel/olpc.c b/arch/x86/kernel/olpc.c
    index 11670be..3a05683 100644
    --- a/arch/x86/kernel/olpc.c
    +++ b/arch/x86/kernel/olpc.c
    @@ -190,11 +190,11 @@ EXPORT_SYMBOL_GPL(olpc_ec_cmd);
    static void __init platform_detect(void)
    {
    size_t propsize;
    - u32 rev;
    + uint32_t rev;

    if (ofw("getprop", 4, 1, NULL, "board-revision-int", &rev, 4,
    &propsize) || propsize != 4) {
    - printk(KERN_ERR "ofw: getprop call failed!\n");
    + printk(KERN_ERR "olpc: ofw getprop call failed!\n");
    rev = 0;
    }
    olpc_platform_info.boardrev = be32_to_cpu(rev);
    @@ -207,26 +207,43 @@ static void __init platform_detect(void)
    }
    #endif

    -static int __init olpc_init(void)
    +static int __init ofw_detect(void)
    {
    - unsigned char *romsig;
    + size_t propsize;
    + char romsig[20];
    + ofw_phandle phandle;

    - spin_lock_init(&ec_lock);
    + /* Fetch /openprom/model */
    + if (ofw("finddevice", 1, 1, "/openprom", &phandle) || phandle == ~0)
    + return -ENODEV;

    - romsig = ioremap(0xffffffc0, 16);
    - if (!romsig)
    - return 0;
    + if (ofw("getprop", 4, 1, phandle, "model", &romsig, sizeof(romsig),
    + &propsize) || propsize < 7)
    + return -ENODEV;

    + /* String should look something like "CL1 Q2D08 Q2D" */
    if (strncmp(romsig, "CL1 Q", 7))
    - goto unmap;
    + return -ENODEV;
    if (strncmp(romsig+6, romsig+13, 3)) {
    - printk(KERN_INFO "OLPC BIOS signature looks invalid. "
    + printk(KERN_INFO "olpc: BIOS signature looks invalid. "
    "Assuming not OLPC\n");
    - goto unmap;
    + return -ENODEV;
    }

    - printk(KERN_INFO "OLPC board with OpenFirmware %.16s\n", romsig);
    + /* Looks like we have OLPC's OFW */
    olpc_platform_info.flags |= OLPC_F_PRESENT;
    + printk(KERN_INFO "olpc: board with OpenFirmware %.16s\n", romsig);
    +
    + return 0;
    +}
    +
    +static int __init olpc_init(void)
    +{
    + spin_lock_init(&ec_lock);
    +
    + /* ensure OFW is available */
    + if (ofw_detect())
    + return 0;

    /* get the platform revision */
    platform_detect();
    @@ -248,8 +265,6 @@ static int __init olpc_init(void)
    olpc_platform_info.boardrev >> 4,
    olpc_platform_info.ecver);

    -unmap:
    - iounmap(romsig);
    return 0;
    }

    --
    1.5.4.4



    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  5. Re: 2.6.25-mm1

    On Sat, 19 Apr 2008 10:38:33 -0700
    Andrew Morton wrote:

    > > On Sat, 19 Apr 2008 09:25:44 -0400 Andres Salomon wrote:
    > > On Fri, 18 Apr 2008 20:29:25 -0700
    > > Andrew Morton wrote:
    > >
    > > > On Fri, 18 Apr 2008 23:10:24 -0400 Joseph Fannin wrote:
    > > >
    > > > > On Fri, Apr 18, 2008 at 01:47:57AM -0700, Andrew Morton wrote:

    [...]
    > > >
    > > > which we probably just shouldn't do this at all unless we're running on the
    > > > OLPC hardware. But we need to do this to find out if we're running on the OLPC
    > > > hardware! Perhaps the warning should just be removed.

    > >
    > > Hm. We could either protect that code with an:
    > >
    > > if (!is_geode())
    > > return;
    > >
    > > Or I could add the OpenFirmware patches which would allow us to get
    > > rid of this code, and instead check for the existence of OFW using
    > > that.
    > >
    > > The former is quick and easy; the latter is (imo) nicer, so long as
    > > people don't have problems w/ the OFW code.
    > >

    >
    > Do both
    >
    > The quick-n-easy version sounds suitable for now.


    Heh, I already had sent the nicer version. If people have some fundamental
    problem w/ it, I can send the quick-n-easy version.


    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  6. Re: 2.6.25-mm1

    On Fri, 18 Apr 2008 20:29:25 -0700
    Andrew Morton wrote:

    > That's
    >
    > WARN_ON_ONCE(is_ram);
    >
    > the changelog for the patch which added that warning is
    > information-free


    it got added with a full changelog, then temporary removed and then added back ;(

    > and there's no code comment explaining what went
    > wrong, which makes things rather harder than they ought to be.
    >
    > Yes it's due to the new OLPC code. olpc_init() has
    >
    > romsig = ioremap(0xffffffc0, 16);
    >
    > which we probably just shouldn't do this at all unless we're running
    > on the OLPC hardware. But we need to do this to find out if we're
    > running on the OLPC hardware! Perhaps the warning should just be
    > removed. --


    calling ioremap() on something which COULD be ram is... REALLY nasty.
    The kernel has to mark that page uncached, for all users and mappings of that memory.
    A second hard case then is to find out when the last ioremap() user has
    released that memory (since there's several cases where different parts of the same
    4K page can be ioremapped) before it can map it cached again. The good news is that
    until this olpc patch got in, there were no users of this capability....
    Instead of outright forbidding it though we added a warn_on to find out if the
    assumption of no users was correct...
    seems it caught some new code which is trying to do this here.

    this code should probably be a lot more careful and check that
    1) there is no actual kernel memory or something else at this region
    (what if there's some other device there? this code could blow up)
    2) the machine won't tripple fault or otherwise throw tantrums if
    this hardcoded value is accessed (not automatic on x86!!)
    3) it only runs if there's a really high degree of confidence that this really is
    an OLPC device.
    or maybe
    4) get this address from some other table or system provided resource




    --
    If you want to reach me at my work email, use arjan@linux.intel.com
    For development, discussion and tips for power savings,
    visit http://www.lesswatts.org
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  7. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon wrote:
    >
    > This adds 32-bit support for calling into OFW from the kernel. It's useful
    > for querying the firmware for misc hardware information, fetching the device
    > tree, etc.
    >
    > There's potentially no reason why other platforms couldn't use this, but
    > currently OLPC is the main user of it.
    >
    > This work was originally done by Mitch Bradley.
    >
    > Signed-off-by: Andres Salomon
    > ---
    > arch/x86/Kconfig | 8 +++++
    > arch/x86/kernel/Makefile | 1 +
    > arch/x86/kernel/head_32.S | 27 ++++++++++++++++
    > arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
    > include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
    > include/asm-x86/setup.h | 1 +
    > 6 files changed, 162 insertions(+), 0 deletions(-)
    > create mode 100644 arch/x86/kernel/ofw.c
    > create mode 100644 include/asm-x86/ofw.h
    >
    > diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    > index 3b9089b..ce56105 100644
    > --- a/arch/x86/Kconfig
    > +++ b/arch/x86/Kconfig
    > @@ -661,6 +661,14 @@ config I8K
    > Say Y if you intend to run this kernel on a Dell Inspiron 8000.
    > Say N otherwise.
    >
    > +config OPEN_FIRMWARE
    > + bool "Support for Open Firmware"
    > + default y if OLPC
    > + ---help---
    > + This option adds support for the implementation of Open Firmware
    > + that is used on the OLPC XO laptop.
    > + If unsure, say N here.
    > +
    > config X86_REBOOTFIXUPS
    > def_bool n
    > prompt "Enable X86 board specific fixups for reboot"
    > diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
    > index 9575754..d33600e 100644
    > --- a/arch/x86/kernel/Makefile
    > +++ b/arch/x86/kernel/Makefile
    > @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
    > obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
    > obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
    > obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
    > +obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
    > obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
    > obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
    > obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
    > diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
    > index 74d87ea..c9d2d00 100644
    > --- a/arch/x86/kernel/head_32.S
    > +++ b/arch/x86/kernel/head_32.S
    > @@ -132,6 +132,33 @@ ENTRY(startup_32)
    > movsl
    > 1:
    >
    > +#ifdef CONFIG_OPEN_FIRMWARE
    > +/*
    > + * If Open Firmware booted us, save the OFW client interface callback address
    > + * and preserve the OFW page mappings by priming the kernel's new page
    > + * directory area with a copy of the OFW page directory. That lets OFW stay
    > + * resident in high memory (high in both the virtual and physical spaces)
    > + * for at least long enough to copy out the device tree.
    > + */
    > + movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
    > + cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
    > + jne 4f
    > +
    > + mov 0x8(%ebp), %eax /* Save callback address */
    > + mov %eax, pa(call_firmware)
    > +
    > + /* Copy the OFW pdir into swapper_pg_dir */
    > + movl %esi, %edx /* save %esi */
    > + movl $pa(swapper_pg_dir), %edi
    > + movl %cr3, %esi /* Source is current pg_dir base address */
    > + movl $1024, %ecx /* Number of page directory entries */
    > + rep
    > + movsl
    > + movl %edx, %esi /* restore %esi */
    > +4:
    > +
    > +#endif
    > +
    > #ifdef CONFIG_PARAVIRT
    > /* This is can only trip for a broken bootloader... */
    > cmpw $0x207, pa(boot_params + BP_version)
    > diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
    > new file mode 100644
    > index 0000000..14036aa
    > --- /dev/null
    > +++ b/arch/x86/kernel/ofw.c
    > @@ -0,0 +1,75 @@
    > +/*
    > + * Open Firmware client interface for 32-bit systems.
    > + *
    > + * Copyright (c) 2007 Mitch Bradley
    > + * Copyright (c) 2007-2008 Andres Salomon
    > + *
    > + * This program is free software; you can redistribute it and/or modify
    > + * it under the terms of the GNU General Public License as published by
    > + * the Free Software Foundation; either version 2 of the License, or
    > + * (at your option) any later version.
    > + */
    > +
    > +#include
    > +#include
    > +#include
    > +#include
    > +
    > +/*
    > + * This code is intended to be portable to any 32-bit Open Firmware
    > + * implementation with a standard client interface that can be
    > + * called when Linux is running.


    how about changing to ofw_32.c?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  8. internal compiler error: SIGSEGV [Was: 2.6.25-mm1]

    On 04/18/2008 10:47 AM, Andrew Morton wrote:
    > ftp://ftp.kernel.org/pub/linux/kerne...25/2.6.25-mm1/


    Hi, I'm not sure by what was this caused.

    LANG=en strace -fo strace_gcc.txt gcc -Wp,-MD,drivers/usb/class/.usblp.o.d
    -nostdinc -isystem /usr/lib64/gcc/x86_64-suse-linux/4.3/include -D__KERNEL__
    -Iinclude -Iinclude2 -I/home/l/latest/xxx/include -include
    include/linux/autoconf.h -I/home/l/latest/xxx/drivers/usb/class
    -Idrivers/usb/class -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
    -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -O2
    -fno-stack-protector -m64 -march=core2 -mno-red-zone -mcmodel=kernel
    -funit-at-a-time -maccumulate-outgoing-args -DCONFIG_AS_CFI=1
    -DCONFIG_AS_CFI_SIGNAL_FRAME=1 -pipe -Wno-sign-compare
    -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2 -mno-3dnow
    -I/home/l/latest/xxx/include/asm-x86/mach-default -Iinclude/asm-x86/mach-default
    -fno-omit-frame-pointer -fno-optimize-sibling-calls -g
    -Wdeclaration-after-statement -Wno-pointer-sign -DMODULE -D"KBUILD_STR(s)=#s"
    -D"KBUILD_BASENAME=KBUILD_STR(usblp)" -D"KBUILD_MODNAME=KBUILD_STR(usblp)"
    /home/l/latest/xxx/drivers/usb/class/usblp.c -S -o usblp.s
    /home/l/latest/xxx/drivers/usb/class/usblp.c: In function 'usblp_submit_read':
    /home/l/latest/xxx/drivers/usb/class/usblp.c:977: internal compiler error:
    Segmentation fault
    Please submit a full bug report,
    with preprocessed source if appropriate.
    See for instructions.




    strace_gcc.txt:
    http://www.fi.muni.cz/~xslaby/sklad/strace_gcc.txt

    preprocessor output available here:
    http://www.fi.muni.cz/~xslaby/sklad/usblp.E

    Reboot fixed it. It happened after few suspend/resume cycles. The preproc output
    differs in no way from after the reboot. Now, the strace looks like:
    5341 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x7f362e004000
    5341 mmap(NULL, 1048576, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1,
    0) = 0x7f362df04000
    5341 brk(0x1964000) = 0x1964000
    5341 brk(0x194c000) = 0x194c000
    5341 brk(0x196d000) = 0x196d000
    5341 brk(0x195a000) = 0x195a000
    5341 mmap(NULL, 143360, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x7f362dee1000
    5341 munmap(0x7f362dee1000, 143360) = 0
    5341 brk(0x1981000) = 0x1981000
    5341 brk(0x196b000) = 0x196b000
    5341 brk(0x1966000) = 0x1966000
    5341 mmap(NULL, 32768, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0)
    = 0x7f362defc000
    5341 brk(0x1988000) = 0x1988000

    at that sigsegv place.

    Some kind of random-brk gcc (gcc-4.3-30) non-readiness?
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  9. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Yinghai Lu wrote:
    > On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon wrote:
    >> This adds 32-bit support for calling into OFW from the kernel. It's useful
    >> for querying the firmware for misc hardware information, fetching the device
    >> tree, etc.
    >>
    >> There's potentially no reason why other platforms couldn't use this, but
    >> currently OLPC is the main user of it.
    >>
    >> This work was originally done by Mitch Bradley.
    >>


    Hm. This interface seems more than a bit ad hoc. In particular, I
    *really* don't like the swapper_pg_dir hack.

    "There must be a better way."

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  10. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sun, 20 Apr 2008 08:07:55 -0400
    "H. Peter Anvin" wrote:

    > Yinghai Lu wrote:
    > > On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon wrote:
    > >> This adds 32-bit support for calling into OFW from the kernel. It's useful
    > >> for querying the firmware for misc hardware information, fetching the device
    > >> tree, etc.
    > >>
    > >> There's potentially no reason why other platforms couldn't use this, but
    > >> currently OLPC is the main user of it.
    > >>
    > >> This work was originally done by Mitch Bradley.
    > >>

    >
    > Hm. This interface seems more than a bit ad hoc. In particular, I
    > *really* don't like the swapper_pg_dir hack.
    >
    > "There must be a better way."
    >
    > -hpa


    I'm certainly open to suggestions.. Otherwise, I'll poke around and
    see if I can come up w/ something.



    --
    Need a kernel or Debian developer? Contact me, I'm looking for contracts.
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  11. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware



    Andres Salomon wrote:
    > On Sun, 20 Apr 2008 08:07:55 -0400
    > "H. Peter Anvin" wrote:
    >
    >
    >> Yinghai Lu wrote:
    >>
    >>> On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon wrote:
    >>>
    >>>> This adds 32-bit support for calling into OFW from the kernel. It's useful
    >>>> for querying the firmware for misc hardware information, fetching the device
    >>>> tree, etc.
    >>>>
    >>>> There's potentially no reason why other platforms couldn't use this, but
    >>>> currently OLPC is the main user of it.
    >>>>
    >>>> This work was originally done by Mitch Bradley.
    >>>>
    >>>>

    >> Hm. This interface seems more than a bit ad hoc. In particular, I
    >> *really* don't like the swapper_pg_dir hack.
    >>
    >> "There must be a better way."
    >>
    >> -hpa
    >>

    >
    > I'm certainly open to suggestions.. Otherwise, I'll poke around and
    > see if I can come up w/ something.
    >


    The x86 architecture doesn't make this problem easy.

    The conventional solution is to have the BIOS operate in real mode.
    When the kernel calls into the BIOS, it has to do a grotesque dance that
    involves jumping through a chain of several segments of different
    flavors, thus gradually shutting down the multi-tiered address
    translation mechanism. Then, if the BIOS is actually operating in
    protected mode (which is necessary if it is larger than 64K, as all
    modern BIOSes are), it has to perform the inverse process, do the
    requested work, then go back into real mode to return to the kernel.
    The net result is that a "call" into the BIOS involves:

    a) Copying the arguments to a real-mode register shadow array
    b) Saving all the registers - general ones and a few special ones too
    c) Far call to a linear-mapped code segment with an execution address in
    the first 1M of memory
    d) Switching to a different stack
    e) Turning off page translation
    f) Switching from protected mode to real mode (or in some cases, V86
    mode instead, which requires an additional Task State Segment dance to
    set the IO permission mask)
    g) Switching to a real-mode interrupt descriptor table

    h) Executing an INT instruction

    I) Performing the inverse of a - g inside the BIOS

    j) Doing the requested work

    K) Performing a - g again to get back into real mode

    l) Executing an "iret" instruction

    M) Performing the inverse of a-g to return to normal operation

    The machinery that you need to do all that is predictably complex -
    extra segment descriptors that are set up just-so, several little code
    fragments that must be at special addresses in the first meg, additional
    stacks, a real-mode interrupt table at a fixed address, and several data
    save arrays. That machinery has to be in assembly language, spanning
    several different instruction set modes.

    Compared to that, I think that sharing one or two page directory entries
    at the very top of the virtual address space is pretty clean and
    simple. With that sharing, the BIOS call is just an ordinary subroutine
    call. (The setup code copies the entire page directory, but only a
    couple of entries are actually needed. The reason for copying the whole
    thing is because it is rather more work to determine the exact number of
    entries necessary, compared to copying everything and then letting Linux
    replace the ones it uses.)

    Every other solution that I know of requires some sort of heroic dance,
    either from the OS or from the BIOS or (usually) both.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  12. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Andres Salomon wrote:
    >
    > I'm certainly open to suggestions.. Otherwise, I'll poke around and
    > see if I can come up w/ something.
    >


    It pretty much depends on what the invariants look like. The
    normal/clean way of doing this kind of thing is via a fixmap entry
    and/or ioremap.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  13. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    Mitch Bradley wrote:
    >
    > The x86 architecture doesn't make this problem easy.
    >


    [long rant about the x86 architecture]

    It would be more useful if you described the actual defined entry
    conditions from OpenFirmware look like, including if they are
    well-defined for all OF implementations or only for OLPC.

    -hpa
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  14. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley wrote:
    >
    >
    >
    > Yinghai Lu wrote:
    >
    > >
    > > how about changing to ofw_32.c?
    > >
    > > YH
    > >
    > >

    >
    > Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
    > seems like a good idea to me.


    Yes.

    BTW, why olpc need OFW runtime service?
    why not just put the info in in ram with some signiture, so
    kernel/util just need to loot at the table if needed?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  15. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware



    Yinghai Lu wrote:
    > On Sat, Apr 19, 2008 at 10:39 AM, Andres Salomon wrote:
    >
    >> This adds 32-bit support for calling into OFW from the kernel. It's useful
    >> for querying the firmware for misc hardware information, fetching the device
    >> tree, etc.
    >>
    >> There's potentially no reason why other platforms couldn't use this, but
    >> currently OLPC is the main user of it.
    >>
    >> This work was originally done by Mitch Bradley.
    >>
    >> Signed-off-by: Andres Salomon
    >> ---
    >> arch/x86/Kconfig | 8 +++++
    >> arch/x86/kernel/Makefile | 1 +
    >> arch/x86/kernel/head_32.S | 27 ++++++++++++++++
    >> arch/x86/kernel/ofw.c | 75 +++++++++++++++++++++++++++++++++++++++++++++
    >> include/asm-x86/ofw.h | 50 ++++++++++++++++++++++++++++++
    >> include/asm-x86/setup.h | 1 +
    >> 6 files changed, 162 insertions(+), 0 deletions(-)
    >> create mode 100644 arch/x86/kernel/ofw.c
    >> create mode 100644 include/asm-x86/ofw.h
    >>
    >> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
    >> index 3b9089b..ce56105 100644
    >> --- a/arch/x86/Kconfig
    >> +++ b/arch/x86/Kconfig
    >> @@ -661,6 +661,14 @@ config I8K
    >> Say Y if you intend to run this kernel on a Dell Inspiron 8000.
    >> Say N otherwise.
    >>
    >> +config OPEN_FIRMWARE
    >> + bool "Support for Open Firmware"
    >> + default y if OLPC
    >> + ---help---
    >> + This option adds support for the implementation of Open Firmware
    >> + that is used on the OLPC XO laptop.
    >> + If unsure, say N here.
    >> +
    >> config X86_REBOOTFIXUPS
    >> def_bool n
    >> prompt "Enable X86 board specific fixups for reboot"
    >> diff --git a/arch/x86/kernel/Makefile b/arch/x86/kernel/Makefile
    >> index 9575754..d33600e 100644
    >> --- a/arch/x86/kernel/Makefile
    >> +++ b/arch/x86/kernel/Makefile
    >> @@ -54,6 +54,7 @@ obj-$(CONFIG_X86_TRAMPOLINE) += trampoline_$(BITS).o
    >> obj-$(CONFIG_X86_MPPARSE) += mpparse_$(BITS).o
    >> obj-$(CONFIG_X86_LOCAL_APIC) += apic_$(BITS).o nmi_$(BITS).o
    >> obj-$(CONFIG_X86_IO_APIC) += io_apic_$(BITS).o
    >> +obj-$(CONFIG_OPEN_FIRMWARE) += ofw.o
    >> obj-$(CONFIG_X86_REBOOTFIXUPS) += reboot_fixups_32.o
    >> obj-$(CONFIG_KEXEC) += machine_kexec_$(BITS).o
    >> obj-$(CONFIG_KEXEC) += relocate_kernel_$(BITS).o crash.o
    >> diff --git a/arch/x86/kernel/head_32.S b/arch/x86/kernel/head_32.S
    >> index 74d87ea..c9d2d00 100644
    >> --- a/arch/x86/kernel/head_32.S
    >> +++ b/arch/x86/kernel/head_32.S
    >> @@ -132,6 +132,33 @@ ENTRY(startup_32)
    >> movsl
    >> 1:
    >>
    >> +#ifdef CONFIG_OPEN_FIRMWARE
    >> +/*
    >> + * If Open Firmware booted us, save the OFW client interface callback address
    >> + * and preserve the OFW page mappings by priming the kernel's new page
    >> + * directory area with a copy of the OFW page directory. That lets OFW stay
    >> + * resident in high memory (high in both the virtual and physical spaces)
    >> + * for at least long enough to copy out the device tree.
    >> + */
    >> + movl $pa(boot_params + OFW_INFO_OFFSET), %ebp
    >> + cmpl $0x2057464F, (%ebp) /* Magic number "OFW " */
    >> + jne 4f
    >> +
    >> + mov 0x8(%ebp), %eax /* Save callback address */
    >> + mov %eax, pa(call_firmware)
    >> +
    >> + /* Copy the OFW pdir into swapper_pg_dir */
    >> + movl %esi, %edx /* save %esi */
    >> + movl $pa(swapper_pg_dir), %edi
    >> + movl %cr3, %esi /* Source is current pg_dir base address */
    >> + movl $1024, %ecx /* Number of page directory entries */
    >> + rep
    >> + movsl
    >> + movl %edx, %esi /* restore %esi */
    >> +4:
    >> +
    >> +#endif
    >> +
    >> #ifdef CONFIG_PARAVIRT
    >> /* This is can only trip for a broken bootloader... */
    >> cmpw $0x207, pa(boot_params + BP_version)
    >> diff --git a/arch/x86/kernel/ofw.c b/arch/x86/kernel/ofw.c
    >> new file mode 100644
    >> index 0000000..14036aa
    >> --- /dev/null
    >> +++ b/arch/x86/kernel/ofw.c
    >> @@ -0,0 +1,75 @@
    >> +/*
    >> + * Open Firmware client interface for 32-bit systems.
    >> + *
    >> + * Copyright (c) 2007 Mitch Bradley
    >> + * Copyright (c) 2007-2008 Andres Salomon
    >> + *
    >> + * This program is free software; you can redistribute it and/or modify
    >> + * it under the terms of the GNU General Public License as published by
    >> + * the Free Software Foundation; either version 2 of the License, or
    >> + * (at your option) any later version.
    >> + */
    >> +
    >> +#include
    >> +#include
    >> +#include
    >> +#include
    >> +
    >> +/*
    >> + * This code is intended to be portable to any 32-bit Open Firmware
    >> + * implementation with a standard client interface that can be
    >> + * called when Linux is running.
    >>

    >
    > how about changing to ofw_32.c?
    >
    > YH
    >


    Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"?
    That seems like a good idea to me.

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  16. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    H. Peter Anvin wrote:
    > Mitch Bradley wrote:
    >>
    >> The x86 architecture doesn't make this problem easy.
    >>

    >
    > [long rant about the x86 architecture]
    >
    > It would be more useful if you described the actual defined entry
    > conditions from OpenFirmware look like, including if they are
    > well-defined for all OF implementations or only for OLPC.
    >
    > -hpa


    Fair enough...

    To get the second subquestion out of the way: At the present time, on
    the x86 architecture, "all OF implementations" and "OLPC" are
    effectively the same. I am unaware of any other x86 OFW deployments in
    current use. There have been some in the past, on bespoke systems such
    as Network Appliance servers and at least one settop box, but those have
    fallen by the wayside as those companies have shifted over to commodity
    PC hardware. The current market status quo is that x86 boards are
    primarily designed for Windows, and thus must run legacy BIOS, with some
    recent migration to EFI, neither of which are open source in the strong
    sense. While I would like to see more OFW penetration into the larger
    x86 market, I don't really expect it. x86 motherboard manufacturing is
    becoming more and more difficult as signal speeds increase, leading to a
    decline in the number of manufacturers. The existing manufacturers
    depend on Windows for sales volume and their internal procedures and
    working knowledge are based on legacy BIOS.

    Once upon a time, we had an OFW "binding" document that stipulated the
    interface conditions, with the intention of making that "standard"
    across all OFW-on-x86 systems. However, by the time OLPC came around,
    there were no other systems to consider, so I felt free to make some
    changes in the interface. I ended up choosing an ABI that resulted in a
    simple (in the sense of not much code, and no complex state transitions)
    interface with 2.6 Linux kernels.

    The interface defined below is not inherently OLPC-specific - it would
    be suitable for any ia32 system that used OFW. (At a higher level, the
    set of OFW callback functions is architecture-neutral; in this message I
    am focusing on the very low-level details of the ia32 ABI)

    The system conditions for the OFW to Linux kernel transition are as follows:

    a) OFW can load the Linux kernel from either bzimage format or ELF
    format (either uncompressed or zlib-compressed.) If the kernel is in
    ELF format with symbols, OFW can do symbolic kernel debugging. Further
    discussion will focus on bzimage format, as that is what OLPC uses and
    is also the "greased path" for kernel builds.

    b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if
    any, at 0x800000.

    c) OFW runs in 32-bit protected mode with paging enabled. There are two
    reasons for this. First, it lets OFW locate itself at the top of both
    physical memory space and virtual address space, the only places that
    are truly "out of the way". It also lets Linux call back into OFW with
    a minimum of bother (similarly helping with the OFW-debugs-Linux scenario).

    d) OFW itself lives at the top of the virtual address space, just below
    the ROM. (The ROM is mapped virtual=physical for convenience) OFW
    uses RAM allocated from the top of physical memory, mapped at the
    aforementioned high virtual addresses. One page directory entry - the
    next to last one - is used for that RAM mapping and also for mapping
    additional miscellaneous I/O devices. The 8MB frame buffer requires 2
    additional PDEs, just below. When Linux takes over the display, OFW no
    longer needs the frame buffer mapping, but it is convenient to preserve
    that mapping temporarily while using OFW as a debugger.

    e) Low memory - everything except the ~1Meg that OFW lives in - is
    mapped virtual=physical.

    f) The code, data, and stack segment descriptors are all for 32-bit 4GB
    linear segments. (For debugging convenience, OFW initially uses the
    same segment numbers as the Linux kernel, but that is not an ABI
    requirement - callbacks into OFW will work from any 32-bit segments that
    encompass the kernel and OFW virtual address space.)

    g) OFW sets up a boot parameter block at 0x90000, with the format as
    defined in include/asm-x86/bootparam.h . The block includes the
    cmdline, memory layout information, screen info, and address/length of
    the ramdisk.

    h) OFW also includes in the boot parameter block an additional
    information block at OFW_INFO_OFFSET. That info block contains:
    "OFW " - 4-byte signature string ('O' at byte offset 0, etc)
    __u32 version - 1
    __u32 callback - (actually a 32-bit function pointer) address of
    callback function
    __u32 idt - address of OFW's interrupt descriptor table, in case
    Linux wants to preserve the breakpoint vector

    i) OFW transfers control to the bzimage with the processor in the
    following state:
    * interrupts masked off at the interrupt controller and in the flags
    register
    * 32-bit protected mode, CS=0x60, DS=ES=FS=GS=SS=0x68
    * ebx=ecx=edx=ebp=edi=0
    * eax = &callback_function
    * esi = 0x90000 (boot parameter block)
    * esp = 0x90000 (short-lived initial stack starts below boot
    parameter block)
    * eip = 0x100000 (entry address of bzimage)
    * paging enabled, with V=P mapping of physical memory and one high
    pde for OFW, as in (d) and (e) above

    j) Linux must save the following information during early startup:
    1) The callback function address - either from the initial value of
    eax or from the OFW info block.
    2) The the next-to-last page directory entry - just the pointer to the
    page table. The page table itself lives in OFW's reserved memory.

    k) When calling back into OFW, Linux must:
    1) Establish a page directory that contains OFW's PDE (saved in j2
    above) and that maps the client interface argument array, including any
    buffer pointers.
    2) Call callback_function with the address of the argument array in
    eax. (Ordinary 32-bit near call).

    For all of the OLPC kernel's current callbacks into OFW, the
    requirements (j2) and (k1) are easily satisfied by "priming"
    swapper_pg_dir with the contents of the current page directory (as
    pointed to by the CR3 register).



    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  17. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware



    Yinghai Lu wrote:
    > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley wrote:
    >
    >>
    >> Yinghai Lu wrote:
    >>
    >>
    >>> how about changing to ofw_32.c?
    >>>
    >>> YH
    >>>
    >>>
    >>>

    >> Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"? That
    >> seems like a good idea to me.
    >>

    >
    > Yes.
    >
    > BTW, why olpc need OFW runtime service?
    > why not just put the info in in ram with some signiture, so
    > kernel/util just need to loot at the table if needed?
    >


    In SPARC land, at least on SunOS and Solaris, it was very convenient for
    debugging to interrupt the OS with Stop-A and use OFW to inspect the
    system state. That was especially handy for live crash analysis. Dumps
    are useful as far as they go, but they often fail to capture detailed
    I/O device state.

    I was hoping to do that on x86 too. So far we (OLPC) haven't
    implemented a sysrq hook to enter OFW, but I haven't given up hope yet.
    It doesn't cost much to leave OFW around, but once you decide to eject
    it, you can't easily get it back.

    Apple made the early decision to eject OFW and just keep a device tree
    table. That decision was probably due to several factors, including the
    rather lame state of Apple's first OFW implementation and the complexity
    of their OS startup process at the time (which included "trampolining"
    to a 68000 emulator to run their legacy code). Once they went down that
    path, the die was cast, and the PowerPC community got used to the "OFW
    ends up as just a table" idea.

    >

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  18. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    From: Mitch Bradley
    Date: Sun, 20 Apr 2008 18:05:26 -1000

    > In SPARC land, at least on SunOS and Solaris, it was very convenient for
    > debugging to interrupt the OS with Stop-A and use OFW to inspect the
    > system state. That was especially handy for live crash analysis. Dumps
    > are useful as far as they go, but they often fail to capture detailed
    > I/O device state.


    In most current SPARC systems, OFW is not usable and is completely
    forgotten right after bootup in order to accomodate LDOMs and CPU
    hotplug.

    It's a better idea, anyways, to develop more pervasive and usable
    in-kernel debugger facilities. Then it doesn't matter if you have
    "cool" firmware or not. :-)

    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  19. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sun, Apr 20, 2008 at 9:05 PM, Mitch Bradley wrote:
    >
    >
    >
    > Yinghai Lu wrote:
    >
    > > On Sun, Apr 20, 2008 at 8:09 PM, Mitch Bradley wrote:
    > >
    > >
    > > >
    > > > Yinghai Lu wrote:
    > > >
    > > >
    > > >
    > > > > how about changing to ofw_32.c?
    > > > >
    > > > > YH
    > > > >
    > > > >
    > > > >
    > > > >
    > > > Is your suggestion to change the filename from "ofw.c" to "ofw_32.c"?

    > That
    > > > seems like a good idea to me.
    > > >
    > > >

    > >
    > > Yes.
    > >
    > > BTW, why olpc need OFW runtime service?
    > > why not just put the info in in ram with some signiture, so
    > > kernel/util just need to loot at the table if needed?
    > >
    > >

    >
    > In SPARC land, at least on SunOS and Solaris, it was very convenient for
    > debugging to interrupt the OS with Stop-A and use OFW to inspect the system
    > state. That was especially handy for live crash analysis. Dumps are useful
    > as far as they go, but they often fail to capture detailed I/O device state.
    >
    > I was hoping to do that on x86 too. So far we (OLPC) haven't implemented a
    > sysrq hook to enter OFW, but I haven't given up hope yet. It doesn't cost
    > much to leave OFW around, but once you decide to eject it, you can't easily
    > get it back.


    geode is using SMI to simulate the pci conf space, wonder that could be problem.

    later you have 64 runtime service for 64 platform like UEFI?

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

  20. Re: [PATCH 1/2] OLPC: Add support for calling into Open Firmware

    On Sun, Apr 20, 2008 at 8:39 PM, Mitch Bradley wrote:
    >
    > H. Peter Anvin wrote:
    >
    > > Mitch Bradley wrote:
    > >
    > > >
    > > > The x86 architecture doesn't make this problem easy.
    > > >
    > > >

    > >
    > > [long rant about the x86 architecture]
    > >
    > > It would be more useful if you described the actual defined entry

    > conditions from OpenFirmware look like, including if they are well-defined
    > for all OF implementations or only for OLPC.
    > >
    > > -hpa
    > >

    >
    > Fair enough...
    >
    > To get the second subquestion out of the way: At the present time, on the
    > x86 architecture, "all OF implementations" and "OLPC" are effectively the
    > same. I am unaware of any other x86 OFW deployments in current use. There
    > have been some in the past, on bespoke systems such as Network Appliance
    > servers and at least one settop box, but those have fallen by the wayside as
    > those companies have shifted over to commodity PC hardware. The current
    > market status quo is that x86 boards are primarily designed for Windows, and
    > thus must run legacy BIOS, with some recent migration to EFI, neither of
    > which are open source in the strong sense. While I would like to see more
    > OFW penetration into the larger x86 market, I don't really expect it. x86
    > motherboard manufacturing is becoming more and more difficult as signal
    > speeds increase, leading to a decline in the number of manufacturers. The
    > existing manufacturers depend on Windows for sales volume and their internal
    > procedures and working knowledge are based on legacy BIOS.
    >
    > Once upon a time, we had an OFW "binding" document that stipulated the
    > interface conditions, with the intention of making that "standard" across
    > all OFW-on-x86 systems. However, by the time OLPC came around, there were
    > no other systems to consider, so I felt free to make some changes in the
    > interface. I ended up choosing an ABI that resulted in a simple (in the
    > sense of not much code, and no complex state transitions) interface with 2.6
    > Linux kernels.
    >
    > The interface defined below is not inherently OLPC-specific - it would be
    > suitable for any ia32 system that used OFW. (At a higher level, the set of
    > OFW callback functions is architecture-neutral; in this message I am
    > focusing on the very low-level details of the ia32 ABI)
    >
    > The system conditions for the OFW to Linux kernel transition are as
    > follows:
    >
    > a) OFW can load the Linux kernel from either bzimage format or ELF format
    > (either uncompressed or zlib-compressed.) If the kernel is in ELF format
    > with symbols, OFW can do symbolic kernel debugging. Further discussion will
    > focus on bzimage format, as that is what OLPC uses and is also the "greased
    > path" for kernel builds.
    >
    > b) OFW loads the bzimage kernel at 0x100000 and the ramdisk image, if any,
    > at 0x800000.


    so you are assuming that your uncompressed vmlinux only use less 8M space?

    you are supposed to check the bzImage to get uncompressed vmlinux size.

    YH
    --
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

+ Reply to Thread
Page 2 of 6 FirstFirst 1 2 3 4 ... LastLast