All of lore.kernel.org
 help / color / mirror / Atom feed
From: Rob Herring <robherring2@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup
Date: Wed, 20 Feb 2013 08:07:22 -0600	[thread overview]
Message-ID: <5124D89A.5030403@gmail.com> (raw)
In-Reply-To: <20130219231428.44C8A200536@gemini.denx.de>

On 02/19/2013 05:14 PM, Wolfgang Denk wrote:
> Dear Rob Herring,
> 
> In message <5123E311.1070607@gmail.com> you wrote:
>>

[snip]

>> What I would really prefer to do is like powerpc where platforms
>> override this if they need the fixup and the default behavior is no
>> fixup. But that would require knowing which platforms do and don't need
>> the fixup. It only going to get harder to change that.
> 
> Normally we use get_ramsize() to check / verify the amount of
> available RAM.  And on PPC, we nearly always set the ram size in the
> DT.  I don't know why you think the default was no fixup; this is not
> true.  It's the other way round.

No it is not.

The fixup is in bootm.c for all of arm, yet appears in all the board/soc
files for powerpc. It may be nearly always fixed up because every platform
duplicates the fixup code, but it is not the default. It is a per platform
decision on powerpc and it is not on arm.

$ git grep fixup_memory
arch/arm/lib/bootm.c:static int fixup_memory_node(void *blob)
arch/arm/lib/bootm.c:   return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
arch/arm/lib/bootm.c:   fixup_memory_node(*of_flat_tree);
arch/powerpc/cpu/74xx_7xx/cpu.c:        fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc512x/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc5xxx/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc8260/cpu.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc83xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc85xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc86xx/fdt.c: fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/mpc8xx/fdt.c:  fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
arch/powerpc/cpu/ppc4xx/fdt.c:  fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
board/exmeritus/hww1u1a/hww1u1a.c:      fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/bsc9131rdb/bsc9131rdb.c:        fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/corenet_ds/corenet_ds.c:        fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/mpc7448hpc2/mpc7448hpc2.c:      fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
board/freescale/mpc8572ds/mpc8572ds.c:  fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p1010rdb/p1010rdb.c:    fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p1022ds/p1022ds.c:      fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p1023rds/p1023rds.c:    fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p1_p2_rdb/p1_p2_rdb.c:  fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c:    fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p2020come/p2020come.c:  fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p2020ds/p2020ds.c:      fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/p2041rdb/p2041rdb.c:    fdt_fixup_memory(blob, (u64)base, (u64)size);
board/freescale/t4qds/t4qds.c:  fdt_fixup_memory(blob, (u64)base, (u64)size);
board/ipek01/ipek01.c:  fdt_fixup_memory (blob, (u64) bd->bi_memstart, (u64) bd->bi_memsize);
board/pdm360ng/pdm360ng.c:      fdt_fixup_memory(blob, (u64)bd->bi_memstart, (u64)bd->bi_memsize);
common/cmd_fdt.c:               err = fdt_fixup_memory(working_fdt, addr, size);
common/fdt_support.c:int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks)
common/fdt_support.c:int fdt_fixup_memory(void *blob, u64 start, u64 size)
common/fdt_support.c:   return fdt_fixup_memory_banks(blob, &start, &size, 1);
include/fdt_support.h:int fdt_fixup_memory(void *blob, u64 start, u64 size);
include/fdt_support.h:int fdt_fixup_memory_banks(void *blob, u64 start[], u64 size[], int banks);

>>> Actually you are reaching here a point where it seems necessary that
>>> U-Boot itself is able to read the DT to configure itself correctly,
>>> i. e. the memory size information it holds should then also be
>>> extracted from the DT.
>>
>> I thought about doing this. That's really an orthogonal issue. The
>> problem is you cannot adjust the amount of memory u-boot uses to be
>> different than the amount of RAM in the /memory node. If you adjust the
>> size in u-boot, the adjusted size is passed to the kernel no matter what.
>>
>> There's issues with LPAE systems having >4GB of RAM as all the size and
>> address values are 32-bit. This could be fixed, but I'm not sure there
>> is much value in u-boot knowing about memory above 4GB as it can't
>> really access all of it and it would be purely informational.
> 
> Well, let's face it - no matter what you do, if the RAM sizes as used
> in U-Boot and in Linux differ, at least one of these is wrong.  This
> is a bug that should be fixed.  What you attempt to do is implementing
> a method to paper over such bugs.  This is not a good thing to do.

We'll probably just have to disagree that u-boot needs to know about 
memory it can't access on 32-bit PAE system unless you want to 
implement paging.

Rob

  reply	other threads:[~2013-02-20 14:07 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-25  3:39 [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup Rob Herring
2013-01-25  3:39 ` [U-Boot] [PATCH 2/2] ARM: highbank: remove DRAM bank setup Rob Herring
2013-02-19 19:27   ` Wolfgang Denk
2013-02-19 16:35 ` [U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup Tom Rini
2013-02-19 19:26 ` Wolfgang Denk
2013-02-19 20:39   ` Rob Herring
2013-02-19 23:14     ` Wolfgang Denk
2013-02-20 14:07       ` Rob Herring [this message]
2013-02-20 14:11       ` Wolfgang Denk
2013-02-20 14:33     ` Tom Rini
2013-02-20 21:55       ` Peter Korsgaard
2013-02-20 22:13         ` 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=5124D89A.5030403@gmail.com \
    --to=robherring2@gmail.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.