linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: grant.likely@secretlab.ca (Grant Likely)
To: linux-arm-kernel@lists.infradead.org
Subject: [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00
Date: Sat, 29 Oct 2011 13:03:20 +0200	[thread overview]
Message-ID: <20111029110320.GD20132@ponder.secretlab.ca> (raw)
In-Reply-To: <20111029084330.GW19187@n2100.arm.linux.org.uk>

On Sat, Oct 29, 2011 at 09:43:30AM +0100, Russell King - ARM Linux wrote:
> On Fri, Oct 28, 2011 at 09:49:49AM -0700, Stephen Warren wrote:
> > When boards boot from DT, there is no fixup function to override the
> > bootloader's ATAGs. I also see a bunch of code to set up the memory
> > information from DT e.g. setup_machine_fdt()'s call to:
> > 
> > 	of_scan_flat_dt(early_init_dt_scan_memory, NULL);
> > 
> > ... but I assume that happens before the ATAGs are processed, and the
> > buggy ATAGs end up overriding the information in the DT file.
> 
> As far as the uncompressed kernel is concerned, there is either ATAG
> or DT information, never both.  If the boot loader provides ATAGs and
> the zImage has a DT appended to it, the zImage decompressor merges the
> ATAGs into the appended DT and passes the DT to the kernel.
> 
> So anyone who currently 'fixes' their broken boot loader via the fixup
> function by directly manipulating the ATAGS is going to hit the DT
> image instead.

Ugh.  Not pretty.  A platform could still have board specific fixup
code that matches on the compatible string that deals with broken
firmware ATAGs, but I don't think that is what we want to do.

We could handle it by filling the .dts file with an empty 'reg'
property for memory, and only push in the legacy ATAG data if reg is
indeed empty.  That gives the option of overriding ATAGs if the DT
already specifies memory.  Need to think about this more.

g.

  reply	other threads:[~2011-10-29 11:03 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <cover.1319658296.git.marvin24@gmx.de>
     [not found] ` <e528a8eb783ace4729e0c76ca72d500d5281c9af.1319658296.git.marvin24@gmx.de>
     [not found]   ` <74CDBE0F657A3D45AFBB94109FB122FF173E1B48D7@HQMAIL01.nvidia.com>
     [not found]     ` <3520326.MNh26pzpGT@fb07-iapwap2>
2011-10-28 16:49       ` [PATCH v2 2/3] arm/dt: tegra: add dts file for paz00 Stephen Warren
2011-10-29  8:43         ` Russell King - ARM Linux
2011-10-29 11:03           ` Grant Likely [this message]
2011-10-29 11:44             ` Russell King - ARM Linux
2011-10-31 15:51           ` Stephen Warren
2011-10-30 20:39         ` Marc Dietrich
2011-10-31  3:13           ` Grant Likely
2011-10-31 16:09           ` Stephen Warren
2011-10-31 18:18             ` Marc Dietrich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20111029110320.GD20132@ponder.secretlab.ca \
    --to=grant.likely@secretlab.ca \
    --cc=linux-arm-kernel@lists.infradead.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).