lkml.org 
[lkml]   [2011]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    From
    Date
    SubjectUpdates to devicetree/arm branch
    Hi all,

    I've just push a few more commits out to devicetree/arm which picks up
    the removal of early machine_type lookup, picks up Rob's
    atags-anywhere patch (an earlier version, not the one rebased on
    Russell's p2v branch; I'll update to Rob's latest in the 2.6.39
    timeframe), and fixes the dtb corruption issue that I ran into (Thanks
    to John Bonesio for the debug help). I was trying to use
    memblock_alloc() for early memory allocation when I should have been
    using alloc_bootmem_align(). Oops.

    Anyway, it seems to be working well for me, but it needs more testing.
    Give it a try if you're interested. The tree details are below:

    John, hopefully this will solve all the dtb base address issues you
    were having. You *should* be able to locate the dtb anywhere in ram
    now, except in a region used by the kernel and it cannot be based at
    physical address 0.

    I'll leave it out there for a day or two and clean some stuff up
    before posting the rebased series for a 3rd round of review.

    Cheers,
    g.

    The following changes since commit ebf53826e105f488f4f628703a108e98940d1dc5:

    Linux 2.6.38-rc3 (2011-02-01 13:05:49 +1000)

    are available in the git repository at:
    git://git.secretlab.ca/git/linux-2.6.git devicetree/arm

    Grant Likely (14):
    arm/dt: Make __vet_atags also accept a dtb image
    arm/dt: allow bootmem reservation for device tree blob and initrd
    arm/dt: consolidate atags setup into setup_machine_atags
    arm/dt: probe for platforms via the device tree
    arm/dt: Basic versatile devicetree support
    arm/tegra: Fix tegra irq_data conversion
    arm/dt: Basic tegra devicetree support
    arm/dt: Fixup bugs in device tree __vet_atags changes
    Merge v2.6.38-rc1 into devicetree/arm
    Merge v2.6.38-rc2 into devicetree/arm
    dt/arm: Save dtb in allocated buffer instead of reserved region
    Merge commit 'v2.6.38-rc3' into devicetree/arm
    arm/dt: Fixed memory allocation and missing of_fdt.h header
    Revert "dt/arm: Save dtb in allocated buffer instead of reserved region"

    Jeremy Kerr (1):
    arm/dt: Allow CONFIG_OF on ARM

    Rob Herring (1):
    ARM/dt: map ATAGs when not in first 1MB of RAM

    Russell King (1):
    arm: Defer lookup of machine_type and vet of atags to setup.c

    arch/arm/Kconfig | 7 ++
    arch/arm/include/asm/mach/arch.h | 2 +
    arch/arm/include/asm/prom.h | 34 +++++++++
    arch/arm/include/asm/setup.h | 4 +
    arch/arm/kernel/Makefile | 1 +
    arch/arm/kernel/devtree.c | 107 +++++++++++++++++++++++++++++
    arch/arm/kernel/head-common.S | 114 +++++--------------------------
    arch/arm/kernel/head-nommu.S | 3 -
    arch/arm/kernel/head.S | 36 +++++++---
    arch/arm/kernel/setup.c | 117 ++++++++++++++++++++++----------
    arch/arm/mach-tegra/board-harmony.c | 6 ++
    arch/arm/mach-versatile/versatile_ab.c | 6 ++
    arch/arm/mach-versatile/versatile_pb.c | 6 ++
    arch/arm/mm/init.c | 22 ++++++
    14 files changed, 318 insertions(+), 147 deletions(-)
    create mode 100644 arch/arm/include/asm/prom.h
    create mode 100644 arch/arm/kernel/devtree.c


    On Tue, Feb 1, 2011 at 11:21 PM, Grant Likely <grant.likely@secretlab.ca> wrote:
    > [restored cc: list]
    >
    > On Tue, Feb 01, 2011 at 08:11:15AM -0700, John Linn wrote:
    >> OK, I see your changes don't really help the problem with device
    >> trees up higher.
    >>
    >> The problem is that in setup_machine_fdt the kernel can't get to the
    >> memory where the device tree is located if it's up higher.
    >
    > No, there is another patch to solve that problem from Rob Herring.
    > I've not yet picked it up into my tree, but I will be doing so soon.
    > For now the dtb needs to be located inside the first 16k of ram.
    >
    > However, it can no longer be based at 0 either.  I discovered that if
    > the dt is based at zero, then the kernel is unable to tell the
    > different between no atags/dtb passed and a dtb passed at physical
    > address 0.  At the very least it needs to be offset about 16 bytes.
    > Since it is common to put atags at address 0x100, it is also
    > reasonable to use 0x100 as the dtb base address too.
    >
    > This problem doesn't exist for machines with ram based at physical
    > address != 0.
    >
    > Sorry I wasn't clear when I posted this.  There is still a bit of flux
    > to get the interface correct and I accidentally glossed over this
    > detail.
    >
    >> The new stuff you added doesn't run early enough to take care of this problem.
    >
    > The problem I was trying to solve is that I was seeing device tree
    > corruption later in the boot process, but it now seems that I might
    > have misdiagnosed it.  I'm still investigation, but I may end up
    > reverting the memblock_reserve() change.
    >
    >>
    >> I probably should have reviewed the patches instead of testing as I
    >> would have realized that.
    >>
    >> I'm looking to see if I can understand how to help the problem.
    >>
    >> Should I really just respond to the mailing list instead of this
    >> back channel?  I don't know good behavior from bad sometimes.
    >
    > Yes, please feel totally free to respond on the mailing list (I went
    > ahead and restored the cc list on this reply).  Just remember to
    > bottom post when replying on-list.
    >
    > g.
    >
    >>
    --
    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/

    \
     
     \ /
      Last update: 2011-02-03 06:53    [W:0.049 / U:34.892 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site