All of lore.kernel.org
 help / color / mirror / Atom feed
From: Tom Rini <trini@ti.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH] lib: Add CONFIG_FDT_IGNORE_FIXUP_MEMORY_NODE
Date: Tue, 8 Apr 2014 12:17:49 -0400	[thread overview]
Message-ID: <20140408161749.GO23803@bill-the-cat> (raw)
In-Reply-To: <20140408130536.357133804B5@gemini.denx.de>

On Tue, Apr 08, 2014 at 03:05:36PM +0200, Wolfgang Denk wrote:
> Dear Nobuhiro,
> 
> In message <CABMQnV+k+Rmx7E8o-nfBpYg5-nWrXi6Oz_+BCYs-vDNdv_z-rw@mail.gmail.com> you wrote:
> > 
> > > Please explain why you would want to do this.  To me it makes no
> > > sense.  Either U-Boot knows the correct memory size, then it should
> > > pass it to Linux.  Or it does not, then U-Boot should be fixed.
> > 
> > For example, I can access the memory of all in the U-Boot, but I may
> > want to control
> > the highmem on Linux,I do not want to show a specific area from kernel
> > and userland.
> 
> Is it not sufficient to pass some "mem=" boot argument?  We even have
> automatic support for this in U-Boot (see the CONFIG_PRAM feature).

There's various ways to do this, yes.  But it doesn't cover the >4GB
case.

> > > Also, I object that your implementation is ARM specific.  If such a
> > > feature gets added, it should be architecture independent.
> > 
> > I see. But arch_fixup_memory_node() is used by ARM only.
> > So, we see to be dependent on the ARM is only this.
> 
> All architectures that support the device tree update the memory size
> for Linux, so we should find a generic way to handle this.  Actually
> we should always strive to reduce this arhitecture specific code.

Note that ARM provides arch_fixup_memory_node to make sure we have all
of the bank information populated and then calls fdt_fixup_memory_banks,
while PowerPC just calls fdt_fixup_memory which calls banks with a '1'
for number of banks.  MIPS (and everyone else) isn't doing anything
about this atm, but probably should.

At the high level, we need to see if we _really_ do need to be using
arch_fixup_memory_node at all because my gut feeling is (a) we've
already always filled in the bank info and if not (b) that is a bug to
correct.  But I haven't dived in to the relevant code here yet.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 836 bytes
Desc: Digital signature
URL: <http://lists.denx.de/pipermail/u-boot/attachments/20140408/71b974f4/attachment.pgp>

  reply	other threads:[~2014-04-08 16:17 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-07  4:56 [U-Boot] [PATCH] lib: Add CONFIG_FDT_IGNORE_FIXUP_MEMORY_NODE Nobuhiro Iwamatsu
2014-04-07  6:53 ` Wolfgang Denk
2014-04-07 17:41   ` Tom Rini
2014-04-08  1:54     ` Nobuhiro Iwamatsu
2014-04-08  1:50   ` Nobuhiro Iwamatsu
2014-04-08 13:05     ` Wolfgang Denk
2014-04-08 16:17       ` Tom Rini [this message]
2014-04-08 16:39         ` thomas.langer at lantiq.com
2014-04-09  3:20         ` Masahiro Yamada
2014-04-09 12:27           ` Tom Rini

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=20140408161749.GO23803@bill-the-cat \
    --to=trini@ti.com \
    --cc=u-boot@lists.denx.de \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.