Updates to devicetree/arm branch

[Grant Likely]

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@xxxxxxxxxxxx> 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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/