[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
has correct memory information, then we don't want or need u-boot to touch
the memory node. Allow platforms to skip this by not filling in dram bank
information.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 arch/arm/lib/board.c |    2 ++
 arch/arm/lib/bootm.c |    4 ++++
 2 files changed, 6 insertions(+)

diff --git a/arch/arm/lib/board.c b/arch/arm/lib/board.c
index cfe32cc..235f953 100644
--- a/arch/arm/lib/board.c
+++ b/arch/arm/lib/board.c
@@ -212,8 +212,10 @@ int print_cpuinfo(void);
 
 void __dram_init_banksize(void)
 {
+#if CONFIG_NR_DRAM_BANKS
 	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
 	gd->bd->bi_dram[0].size =  gd->ram_size;
+#endif
 }
 void dram_init_banksize(void)
 	__attribute__((weak, alias("__dram_init_banksize")));
diff --git a/arch/arm/lib/bootm.c b/arch/arm/lib/bootm.c
index 1bd2730..1f54217 100644
--- a/arch/arm/lib/bootm.c
+++ b/arch/arm/lib/bootm.c
@@ -79,6 +79,7 @@ void arch_lmb_reserve(struct lmb *lmb)
 #ifdef CONFIG_OF_LIBFDT
 static int fixup_memory_node(void *blob)
 {
+#if CONFIG_NR_DRAM_BANKS
 	bd_t	*bd = gd->bd;
 	int bank;
 	u64 start[CONFIG_NR_DRAM_BANKS];
@@ -90,6 +91,9 @@ static int fixup_memory_node(void *blob)
 	}
 
 	return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
+#else
+	return 0;
+#endif
 }
 #endif
 
-- 
1.7.10.4

[U-Boot] [PATCH 2/2] ARM: highbank: remove DRAM bank setup

[Rob Herring]

From: Rob Herring <rob.herring@calxeda.com>

The memory sizes in highbank dtb's are already correct, so remove the DRAM
bank setup so the memory node is not fixed up by u-boot.

Signed-off-by: Rob Herring <rob.herring@calxeda.com>
---
 board/highbank/highbank.c  |    6 ------
 include/configs/highbank.h |    2 +-
 2 files changed, 1 insertion(+), 7 deletions(-)

diff --git a/board/highbank/highbank.c b/board/highbank/highbank.c
index f41bf05..647bd56 100644
--- a/board/highbank/highbank.c
+++ b/board/highbank/highbank.c
@@ -79,12 +79,6 @@ int dram_init(void)
 	return 0;
 }
 
-void dram_init_banksize(void)
-{
-	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
-	gd->bd->bi_dram[0].size =  PHYS_SDRAM_1_SIZE;
-}
-
 void reset_cpu(ulong addr)
 {
 	writel(HB_PWR_HARD_RESET, HB_SREG_A9_PWR_REQ);
diff --git a/include/configs/highbank.h b/include/configs/highbank.h
index 62cc08c..a0fe2c3 100644
--- a/include/configs/highbank.h
+++ b/include/configs/highbank.h
@@ -97,7 +97,7 @@
 /*-----------------------------------------------------------------------
  * Physical Memory Map
  */
-#define CONFIG_NR_DRAM_BANKS		1
+#define CONFIG_NR_DRAM_BANKS		0
 #define PHYS_SDRAM_1_SIZE		(4089 << 20)
 #define CONFIG_SYS_MEMTEST_START	0x100000
 #define CONFIG_SYS_MEMTEST_END		(PHYS_SDRAM_1_SIZE - 0x100000)
-- 
1.7.10.4

[U-Boot] [PATCH 2/2] ARM: highbank: remove DRAM bank setup

[Wolfgang Denk]

Dear Rob Herring,

In message <1359085160-28675-2-git-send-email-robherring2@gmail.com> you wrote:
>
> The memory sizes in highbank dtb's are already correct, so remove the DRAM
> bank setup so the memory node is not fixed up by u-boot.

I think you do more here...

> -void dram_init_banksize(void)
> -{
> -	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
> -	gd->bd->bi_dram[0].size =  PHYS_SDRAM_1_SIZE;
> -}
...
> -#define CONFIG_NR_DRAM_BANKS		1
> +#define CONFIG_NR_DRAM_BANKS		0

I think this is a very bad idea, as you will now be no longer possible
to get information about memory sizes from U-Boot.  For exmaple,
"bdinfo" will not print any reasonable value any more.

Please don't do that!

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Ever try. Ever fail. No matter. Try again. Fail again.  Fail  better.
                                                        -- S. Beckett

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Tom Rini]

On Thu, Jan 24, 2013 at 09:39:19PM -0600, Rob Herring wrote:

> From: Rob Herring <rob.herring@calxeda.com>
> 
> Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
> has correct memory information, then we don't want or need u-boot to touch
> the memory node. Allow platforms to skip this by not filling in dram bank
> information.
> 
> Signed-off-by: Rob Herring <rob.herring@calxeda.com>

OK.  With the notion that it's best to not fiddle with already correct
things, we should have a way "out" there.  But this patch means that
bd->bi_dram is never set which looks to have some bad side-effects for
cache (see arch/arm/lib/cache-cp15.c) so can we come up with some other
way out here?  Thanks!

-- 
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/20130219/0809c041/attachment.pgp>

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Wolfgang Denk]

Dear Rob Herring,

In message <1359085160-28675-1-git-send-email-robherring2@gmail.com> you wrote:
> 
> Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
> has correct memory information, then we don't want or need u-boot to touch
> the memory node. Allow platforms to skip this by not filling in dram bank
> information.

Well, if this is what you want, then please implement just this, and
do not do much more.

>  void __dram_init_banksize(void)
>  {
> +#if CONFIG_NR_DRAM_BANKS
>  	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>  	gd->bd->bi_dram[0].size =  gd->ram_size;
> +#endif
>  }

This change will leave the memory information in struct bd_info
uninitialized, so the "bdinfo" command will print just bogus data.

This is not a good idea.

> --- a/arch/arm/lib/bootm.c
> +++ b/arch/arm/lib/bootm.c
> @@ -79,6 +79,7 @@ void arch_lmb_reserve(struct lmb *lmb)
>  #ifdef CONFIG_OF_LIBFDT
>  static int fixup_memory_node(void *blob)
>  {
> +#if CONFIG_NR_DRAM_BANKS
>  	bd_t	*bd = gd->bd;
>  	int bank;
>  	u64 start[CONFIG_NR_DRAM_BANKS];
> @@ -90,6 +91,9 @@ static int fixup_memory_node(void *blob)
>  	}
>  
>  	return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
> +#else
> +	return 0;
> +#endif

I dislike this.  If you want to make a property of your device tree
"immutable", then you should mark it there as such.  Instead of
removing the code here, U-Boot should then check for such a property
and leave the value unchanged.

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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
The faster I go, the behinder I get.                 -- Lewis Carroll

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Rob Herring]

On 02/19/2013 01:26 PM, Wolfgang Denk wrote:
> Dear Rob Herring,
> 
> In message <1359085160-28675-1-git-send-email-robherring2@gmail.com> you wrote:
>>
>> Currently, u-boot will always fixup the DT memory node on ARM. If the dtb
>> has correct memory information, then we don't want or need u-boot to touch
>> the memory node. Allow platforms to skip this by not filling in dram bank
>> information.
> 
> Well, if this is what you want, then please implement just this, and
> do not do much more.
> 
>>  void __dram_init_banksize(void)
>>  {
>> +#if CONFIG_NR_DRAM_BANKS
>>  	gd->bd->bi_dram[0].start = CONFIG_SYS_SDRAM_BASE;
>>  	gd->bd->bi_dram[0].size =  gd->ram_size;
>> +#endif
>>  }
> 
> This change will leave the memory information in struct bd_info
> uninitialized, so the "bdinfo" command will print just bogus data.
> 
> This is not a good idea.

This hunk can be dropped I think.

>> --- a/arch/arm/lib/bootm.c
>> +++ b/arch/arm/lib/bootm.c
>> @@ -79,6 +79,7 @@ void arch_lmb_reserve(struct lmb *lmb)
>>  #ifdef CONFIG_OF_LIBFDT
>>  static int fixup_memory_node(void *blob)
>>  {
>> +#if CONFIG_NR_DRAM_BANKS
>>  	bd_t	*bd = gd->bd;
>>  	int bank;
>>  	u64 start[CONFIG_NR_DRAM_BANKS];
>> @@ -90,6 +91,9 @@ static int fixup_memory_node(void *blob)
>>  	}
>>  
>>  	return fdt_fixup_memory_banks(blob, start, size, CONFIG_NR_DRAM_BANKS);
>> +#else
>> +	return 0;
>> +#endif
> 
> I dislike this.  If you want to make a property of your device tree
> "immutable", then you should mark it there as such.  Instead of
> removing the code here, U-Boot should then check for such a property
> and leave the value unchanged.

There is no such way defined to flag that and I'm not going to invent
one. It's not that the memory node is immutable, but the default should
not be "needs fixups". No one puts purposely wrong data in their DT. So
therefore all data should be immutable? What happens when we need to
fixup immutable data?

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.

> 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.

Rob

> 
> Best regards,
> 
> Wolfgang Denk
> 

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Wolfgang Denk]

Dear Rob Herring,

In message <5123E311.1070607@gmail.com> you wrote:
>
> > I dislike this.  If you want to make a property of your device tree
> > "immutable", then you should mark it there as such.  Instead of
> > removing the code here, U-Boot should then check for such a property
> > and leave the value unchanged.
> 
> There is no such way defined to flag that and I'm not going to invent
> one. It's not that the memory node is immutable, but the default should
> not be "needs fixups". No one puts purposely wrong data in their DT. So
> therefore all data should be immutable? What happens when we need to
> fixup immutable data?

There is for example the "status" property, which can take the values
"okay" or "disabled".  This is used in other places for not so
unsimilar purposes.


> 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.


> > 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.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
I've got a bad feeling about this.

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Rob Herring]

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

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Wolfgang Denk]

Dear Rob,

In message <20130219231428.44C8A200536@gemini.denx.de> I wrote:
> 
> > There is no such way defined to flag that and I'm not going to invent
> > one. It's not that the memory node is immutable, but the default should
> > not be "needs fixups". No one puts purposely wrong data in their DT. So
> > therefore all data should be immutable? What happens when we need to
> > fixup immutable data?
> 
> There is for example the "status" property, which can take the values
> "okay" or "disabled".  This is used in other places for not so
> unsimilar purposes.

Actually it's even much simpler than that.

If you look for example at PPC, you will see many memory nodes in the
DTB that look like this one (this example is from
arch/powerpc/boot/dts/canyonlands.dts):

	memory {
		device_type = "memory";
		reg = <0x00000000 0x00000000 0x00000000>; /* Filled in by U-Boot */
	};

I. e. the DT provides only dummy values.

How about checking for these - if the DT contains such dummy entries,
U-Boot will insert valid data; if the DT already contains real data,
these take preference?  [And if the latter differ from what U-Boot
thinks is correct, then a big fat warning should be issued!]

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God made the integers; all else is the work of Man.       - Kronecker

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Tom Rini]

On Tue, Feb 19, 2013 at 02:39:45PM -0600, Rob Herring wrote:
> On 02/19/2013 01:26 PM, Wolfgang Denk wrote:
[snip]
> > I dislike this.  If you want to make a property of your device tree
> > "immutable", then you should mark it there as such.  Instead of
> > removing the code here, U-Boot should then check for such a property
> > and leave the value unchanged.
> 
> There is no such way defined to flag that and I'm not going to invent
> one. It's not that the memory node is immutable, but the default should
> not be "needs fixups". No one puts purposely wrong data in their DT. So
> therefore all data should be immutable? What happens when we need to
> fixup immutable data?

It's not so simple.  The first DTs I checked are the am335x ones and I
see they hardcode to 256MB which isn't right, but no one has caught this
since it's blindly fixed up.  So as Wolfgang suggests next, we might
need to go with replacing on 0x0 entries and warning when they don't
match what U-Boot has detected.

-- 
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/20130220/01c927c5/attachment.pgp>

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Peter Korsgaard]

>>>>> "Tom" == Tom Rini <trini@ti.com> writes:

Hi,

 Tom> It's not so simple.  The first DTs I checked are the am335x ones
 Tom> and I see they hardcode to 256MB which isn't right, but no one has
 Tom> caught this since it's blindly fixed up.  So as Wolfgang suggests
 Tom> next, we might need to go with replacing on 0x0 entries and
 Tom> warning when they don't match what U-Boot has detected.

It is correct for the (classic) beaglebone. This also hits people using
appended dtb unless they have CONFIG_ARM_ATAG_DTB_COMPAT enabled (which
the probably do though).

-- 
Bye, Peter Korsgaard

[U-Boot] [PATCH 1/2] ARM: bootm: allow skipping fdt memory node fixup

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 02/20/2013 04:55 PM, Peter Korsgaard wrote:
>>>>>> "Tom" == Tom Rini <trini@ti.com> writes:
> 
> Hi,
> 
> Tom> It's not so simple.  The first DTs I checked are the am335x
> ones Tom> and I see they hardcode to 256MB which isn't right, but
> no one has Tom> caught this since it's blindly fixed up.  So as
> Wolfgang suggests Tom> next, we might need to go with replacing on
> 0x0 entries and Tom> warning when they don't match what U-Boot has
> detected.
> 
> It is correct for the (classic) beaglebone. This also hits people
> using appended dtb unless they have CONFIG_ARM_ATAG_DTB_COMPAT
> enabled (which the probably do though).

So yes, there are some cases where 256MB is the right value.  But we
always know dynamically how much we have, so we don't need to
hard-code even in that case.  And once we do change the behaviour, the
appeneded tree hack shouldn't be relevant anyhow :)

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRJUqnAAoJENk4IS6UOR1WAmgQALOHeh+p9aRLT+Hb0ZjpJk0c
XGJzCO1EpdNpQBsgPxI2AzhPEHsVHgcdzXmzljHS4ukPWDbqihM4j7o9OHjuxAGY
+8Yebw/E/1F7+wKXy013/3QFbl9mdd1OpTU95xarnaoe4+dP5pfa+Q/kH5mrc0U2
xiA4kDmInityA/DUuEP4d8mhnLQyn11CKS/LPKdT40HUGDk6ffzkmUCYEHBpwk11
QN7w6icIGE9JrMsQUOPir7CNDZsNCbeAtB8+gpStHxL63cHqxAh9R3yFyUc2uVHo
5NNkc71R0qLIrKMTbDjIfm1soTEWP94ob6VVPQafqSC7wQrK5r+2DNg9I7dN7xIr
js5Y/BBbPuUZfMWiNWiyF+ONuoNNrz1+iLm9iLdaJajf5EuBQN/qUzNGKFTCsLne
nR6cR0x/Ow+rN1TDmnSvmS845XUDK2qLY5nSthKieuFtoDY88j6VpR4ZO7+B6sSa
9MVx6LV8SO4USewl1FIpXoe6KC2AjdSK2rJN5i2SSQD6uxYzPCfBKezG7gi8Mfua
v4M9W/jDU/avXo861XLeKgcZx0zA7PHxDhqgZDVbFs3QH3eobzZHGog001vM6mvr
dEdUGxu0dVF9ocbF/2F6XxdMVxt2CK7ddbGCZy5V1R6ZCvOVZetCbQao8GB7ZqLU
LMZf4b3iDGdrOfM57n5m
=8tud
-----END PGP SIGNATURE-----