Patchwork [U-Boot,2/2] powerpc/85xx: standardize display of address map size (32-bit vs. 36-bit)

login
register
mail settings
Submitter Timur Tabi
Date Aug. 31, 2011, 10:15 p.m.
Message ID <1314828916-17931-2-git-send-email-timur@freescale.com>
Download mbox | patch
Permalink /patch/112694/
State Superseded
Headers show

Comments

Timur Tabi - Aug. 31, 2011, 10:15 p.m.
Most 85xx boards can be built as a 32-bit or a 36-bit.  Current code sometimes
displays which of these is actually built, but it's inconsistent.  This is
especially problematic since the "default" build for a given 85xx board can
be either one, so if you don't see a message, you can't always know which
size is being used.  Not only that, but each board includes code that displays
the message, so there is duplication.

So if a given SOC can support 36-bit addresses, display one of these two
messages during boot:

	ADDR:  32-bit address map

or

	ADDR:  36-bit address map

Also delete the board-specific code that does this.

Signed-off-by: Timur Tabi <timur@freescale.com>
---
 arch/powerpc/cpu/mpc85xx/cpu_init.c         |   12 ++++++++++++
 board/freescale/corenet_ds/corenet_ds.c     |    4 ----
 board/freescale/mpc8536ds/mpc8536ds.c       |    7 +------
 board/freescale/mpc8572ds/mpc8572ds.c       |    6 +-----
 board/freescale/p1010rdb/p1010rdb.c         |    6 +-----
 board/freescale/p1022ds/p1022ds.c           |    8 ++------
 board/freescale/p1_p2_rdb/p1_p2_rdb.c       |    4 +---
 board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c |    8 +-------
 board/freescale/p2020ds/p2020ds.c           |    8 ++------
 board/freescale/p2041rdb/p2041rdb.c         |    4 ----
 10 files changed, 21 insertions(+), 46 deletions(-)
Kumar Gala - Sept. 1, 2011, 2:07 p.m.
On Aug 31, 2011, at 5:15 PM, Timur Tabi wrote:

> Most 85xx boards can be built as a 32-bit or a 36-bit.  Current code sometimes
> displays which of these is actually built, but it's inconsistent.  This is
> especially problematic since the "default" build for a given 85xx board can
> be either one, so if you don't see a message, you can't always know which
> size is being used.  Not only that, but each board includes code that displays
> the message, so there is duplication.
> 
> So if a given SOC can support 36-bit addresses, display one of these two
> messages during boot:
> 
> 	ADDR:  32-bit address map
> 
> or
> 
> 	ADDR:  36-bit address map
> 
> Also delete the board-specific code that does this.
> 
> Signed-off-by: Timur Tabi <timur@freescale.com>
> ---
> arch/powerpc/cpu/mpc85xx/cpu_init.c         |   12 ++++++++++++
> board/freescale/corenet_ds/corenet_ds.c     |    4 ----
> board/freescale/mpc8536ds/mpc8536ds.c       |    7 +------
> board/freescale/mpc8572ds/mpc8572ds.c       |    6 +-----
> board/freescale/p1010rdb/p1010rdb.c         |    6 +-----
> board/freescale/p1022ds/p1022ds.c           |    8 ++------
> board/freescale/p1_p2_rdb/p1_p2_rdb.c       |    4 +---
> board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c |    8 +-------
> board/freescale/p2020ds/p2020ds.c           |    8 ++------
> board/freescale/p2041rdb/p2041rdb.c         |    4 ----
> 10 files changed, 21 insertions(+), 46 deletions(-)
> 
> diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> index 27f836c..d691726 100644
> --- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
> +++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
> @@ -302,6 +302,18 @@ int cpu_init_r(void)
> 	sync();
> #endif
> 
> +	/*
> +	 * If we support 36-bit addressing, then display whether this is a
> +	 * 32-bit build or a 36-bit build.
> +	 */
> +#ifdef CONFIG_ENABLE_36BIT_PHYS
> +#ifdef CONFIG_PHYS_64BIT

#if defined(A) && defined(B)

> +	puts("ADDR:  36-bit address map\n");
> +#else
> +	puts("ADDR:  32-bit address map\n");
> +#endif
> +#endif
> +
> 	puts ("L2:    ");
> 
> #if defined(CONFIG_L2_CACHE)

Wolfgang's being making comments about reducing the boot info we've been outputting so would like his 2 cents on this.

- k
Timur Tabi - Sept. 1, 2011, 2:13 p.m.
On Sep 1, 2011, at 9:07 AM, Kumar Gala <kumar.gala@freescale.com> wrote:

> 
> On Aug 31, 2011, at 5:15 PM, Timur Tabi wrote:
> 
>> 
>> +    /*
>> +     * If we support 36-bit addressing, then display whether this is a
>> +     * 32-bit build or a 36-bit build.
>> +     */
>> +#ifdef CONFIG_ENABLE_36BIT_PHYS
>> +#ifdef CONFIG_PHYS_64BIT
> 
> #if defined(A) && defined(B)

That's not what I want to do.  Look at the code more closely. 

> 
> Wolfgang's being making comments about reducing the boot info we've been outputting so would like his 2 cents on this.

I understand that, but the patch description explains why this is important.  
>
Wolfgang Denk - Sept. 1, 2011, 2:22 p.m.
Dear Kumar Gala,

In message <CA7ACAD5-C754-4F8A-BE2E-97E04DD005B2@freescale.com> you wrote:
> 
> Wolfgang's being making comments about reducing the boot info we've been =
> outputting so would like his 2 cents on this.

I understand that this is just replacing the implementation, i. e. not
adding new output.

But you are right - I'd much rather see this printed for example as
part of the "bdinfo" command than with the regular boot messages.

Best regards,

Wolfgang Denk
Timur Tabi - Sept. 1, 2011, 2:54 p.m.
Wolfgang Denk wrote:
> But you are right - I'd much rather see this printed for example as
> part of the "bdinfo" command than with the regular boot messages.

Recently, we've been adding boards that have CONFIG_PCI_SCAN_SHOW defined.  Are
you saying that we should not be doing that?  That adds a lot more text than my
patch does.

Examples:
http://patchwork.ozlabs.org/patch/108682/
http://patchwork.ozlabs.org/patch/108533/

Kumar, are you okay with not displaying the address map size at all during boot
time?  If we bury this information in the 'bdinfo' command, we're going to have
even more confusion as to which U-Boot we're booting.
Wolfgang Denk - Sept. 1, 2011, 9:59 p.m.
Dear Timur Tabi,

In message <4E5F9C8D.3080503@freescale.com> you wrote:
> Wolfgang Denk wrote:
> > But you are right - I'd much rather see this printed for example as
> > part of the "bdinfo" command than with the regular boot messages.
> 
> Recently, we've been adding boards that have CONFIG_PCI_SCAN_SHOW defined.  Are
> you saying that we should not be doing that?  That adds a lot more text than my
> patch does.

Yes, that's what I'm sayin.  All this "useful" information should be
available easily to everybody who is interested in it - no boubt of
that.  But it shoudld NOT be printed on each and every boot.

> Kumar, are you okay with not displaying the address map size at all during boot
> time?  If we bury this information in the 'bdinfo' command, we're going to have
> even more confusion as to which U-Boot we're booting.

What sort of "confusion" do you have?  I see two situations:  in
99.99% of all cases U-Boot is just a means to boot an OS, and nobody
cares a bit about the actual U-Boot output, as long as the OS is
runnign after a few seconds, and rather sooner than later.  For a few
use cases where developers are working on a board, they might wonder
which state a board is in - then itis very useful to have a command to
display this information any time they are interested in it - even
without having to reboot the system.

It is actually pretty silly to print certain interesting information
only at boot time.

Best regards,

Wolfgang Denk
Timur Tabi - Sept. 1, 2011, 10:09 p.m.
Wolfgang Denk wrote:
> What sort of "confusion" do you have?  I see two situations:  in
> 99.99% of all cases U-Boot is just a means to boot an OS, and nobody
> cares a bit about the actual U-Boot output, as long as the OS is
> runnign after a few seconds, and rather sooner than later. 

The confusion stems mostly from the fact that we've been displaying this
information for years.  If suddenly we stop displaying it, people are going to
think that something is wrong.  Also, you need to know which U-Boot you're
running before you boot the kernel, because the device tree needs to match.  No
one is going to think to use the 'bdinfo' command to find it.

Many board configurations come in 32-bit and 36-bit versions.  E.g.

make P1022DS_config
vs.
make P1022DS_36BIT_config

The problem is that this isn't standard.  "make P1022DS" builds a 32-bit U-Boot.
 But "make P4080DS" builds a 36-bit U-Boot.  So we've been displaying the
address map size at boot time in some situations, but not all.  My patch makes
this standard.

> For a few
> use cases where developers are working on a board, they might wonder
> which state a board is in - then itis very useful to have a command to
> display this information any time they are interested in it - even
> without having to reboot the system.

I agree with adding that information to the bdinfo command.  I'm just worried
about having it available only there.
Kumar Gala - Sept. 2, 2011, 3:38 a.m.
On Sep 1, 2011, at 4:59 PM, Wolfgang Denk wrote:

> Dear Timur Tabi,
> 
> In message <4E5F9C8D.3080503@freescale.com> you wrote:
>> Wolfgang Denk wrote:
>>> But you are right - I'd much rather see this printed for example as
>>> part of the "bdinfo" command than with the regular boot messages.
>> 
>> Recently, we've been adding boards that have CONFIG_PCI_SCAN_SHOW defined.  Are
>> you saying that we should not be doing that?  That adds a lot more text than my
>> patch does.
> 
> Yes, that's what I'm sayin.  All this "useful" information should be
> available easily to everybody who is interested in it - no boubt of
> that.  But it shoudld NOT be printed on each and every boot.
> 
>> Kumar, are you okay with not displaying the address map size at all during boot
>> time?  If we bury this information in the 'bdinfo' command, we're going to have
>> even more confusion as to which U-Boot we're booting.
> 
> What sort of "confusion" do you have?  I see two situations:  in
> 99.99% of all cases U-Boot is just a means to boot an OS, and nobody
> cares a bit about the actual U-Boot output, as long as the OS is
> runnign after a few seconds, and rather sooner than later.  For a few
> use cases where developers are working on a board, they might wonder
> which state a board is in - then itis very useful to have a command to
> display this information any time they are interested in it - even
> without having to reboot the system.
> 
> It is actually pretty silly to print certain interesting information
> only at boot time.

I agree with this, however I think it should be left to the board config/port to decide if it wants to print and enable this info on boot.  The FSL PPC board ports are not the typical use case.  I view our board ports having a few different purposes:
* Examples for people building their own boards
* Used for customer evaluation and support

Having the additional information printed on boot is extremely useful to FSL for our board ports for supporting customers.  So my take is the following:

1. We reduce the amount printed in the "default" case
2. First choice should always be to have a command the print status info 
3. Allow a board port to makes its own decision if it wants to do something like enable CONFIG_PCI_SCAN_SHOW

Any concerns w/that proposal?

- k
Tabi Timur-B04825 - Sept. 2, 2011, 11:36 a.m.
Kumar Gala wrote:
> 1. We reduce the amount printed in the "default" case
> 2. First choice should always be to have a command the print status info
> 3. Allow a board port to makes its own decision if it wants to do something like enable CONFIG_PCI_SCAN_SHOW
>
> Any concerns w/that proposal?

Are you talking about my patch, or about CONFIG_PCI_SCAN_SHOW?

The reason I like my patch as-is is because it completely eliminates the 
board from the decision.  It's only one line, and it's CONSISTENT.  That's 
the key part.  We have not been consistent about this, and it seems silly 
for each board to implement the same feature.
Kumar Gala - Sept. 2, 2011, 1:12 p.m.
On Sep 2, 2011, at 6:36 AM, Tabi Timur-B04825 wrote:

> Kumar Gala wrote:
>> 1. We reduce the amount printed in the "default" case
>> 2. First choice should always be to have a command the print status info
>> 3. Allow a board port to makes its own decision if it wants to do something like enable CONFIG_PCI_SCAN_SHOW
>> 
>> Any concerns w/that proposal?
> 
> Are you talking about my patch, or about CONFIG_PCI_SCAN_SHOW?
> 
> The reason I like my patch as-is is because it completely eliminates the 
> board from the decision.  It's only one line, and it's CONSISTENT.  That's 
> the key part.  We have not been consistent about this, and it seems silly 
> for each board to implement the same feature.

Both.  I'm think for your patch we'd add some general config option for extra print info.

- k
Timur Tabi - Sept. 2, 2011, 1:41 p.m.
Kumar Gala wrote:
> Both.  I'm think for your patch we'd add some general config option for extra print info.

So you want to see this instead:

/*
 * Display whether this is a 32-bit build or a 36-bit build.
 */
#ifdef CONFIG_DISPLAY_ADDR_SIZE
#ifdef CONFIG_PHYS_64BIT
	puts("ADDR:  36-bit address map\n");
#else
	puts("ADDR:  32-bit address map\n");
#endif
#endif

I still like my way better.  It eliminates the need to think about another
CONFIG option.  I think adding another CONFIG option is worse than adding
another line of text.

It think it's silly to complain about adding one line of text that is only
displayed on e500 systems that support 36-bit addressing, especially since we
display this information on most of our boards anyway.  Surely we can find some
other line of text that we can shorten or eliminate to make up for it.

For instance, we can combine these two lines into one:

CPU0:  P1022E, Version: 1.0, (0x80ee0010)
Core:  E500, Version: 5.0, (0x80211050)

or these two lines:

L1:    D-cache 32 kB enabled
       I-cache 32 kB enabled
Kumar Gala - Sept. 2, 2011, 6:24 p.m.
On Sep 2, 2011, at 8:41 AM, Timur Tabi wrote:

> Kumar Gala wrote:
>> Both.  I'm think for your patch we'd add some general config option for extra print info.
> 
> So you want to see this instead:
> 
> /*
> * Display whether this is a 32-bit build or a 36-bit build.
> */
> #ifdef CONFIG_DISPLAY_ADDR_SIZE
> #ifdef CONFIG_PHYS_64BIT
> 	puts("ADDR:  36-bit address map\n");
> #else
> 	puts("ADDR:  32-bit address map\n");
> #endif
> #endif
> 
> I still like my way better.  It eliminates the need to think about another
> CONFIG option.  I think adding another CONFIG option is worse than adding
> another line of text.

I think we could introduce kernel style "printk" levels that would allow more control over something like this.

- k
Timur Tabi - Sept. 2, 2011, 6:25 p.m.
Kumar Gala wrote:
> I think we could introduce kernel style "printk" levels that would allow more control over something like this.
> 

Or we could implement Kconfig and defconfigs.  But neither of these options is
going to help me now.
Wolfgang Denk - Sept. 2, 2011, 10:10 p.m.
Dear Kumar Gala,

In message <A324986C-C4BF-459A-83AC-2B753FED7A1F@kernel.crashing.org> you wrote:
> 
> I think we could introduce kernel style "printk" levels that would allow =
> more control over something like this.

We can invent many things, or we can keep the code lean and simple.

Let's just move this to where it belongs - to some command that prints
that information upon explicit request of the user.  "bdinfo" comes to
mind here.  Feel free to run such a command as "preboot" sequence then.

Best regards,

Wolfgang Denk
Wolfgang Denk - Sept. 5, 2011, 2:11 p.m.
Dear Timur Tabi,

In message <4E6002B4.90503@freescale.com> you wrote:
>
> > What sort of "confusion" do you have?  I see two situations:  in
> > 99.99% of all cases U-Boot is just a means to boot an OS, and nobody
> > cares a bit about the actual U-Boot output, as long as the OS is
> > runnign after a few seconds, and rather sooner than later. 
> 
> The confusion stems mostly from the fact that we've been displaying this
> information for years.  If suddenly we stop displaying it, people are going to
> think that something is wrong.  Also, you need to know which U-Boot you're
> running before you boot the kernel, because the device tree needs to match.  No
> one is going to think to use the 'bdinfo' command to find it.

Software changes, output changes.  Document your changes if you want
to make sure your users happy.  Feel free to send them detailled
changed logs.

> The problem is that this isn't standard.  "make P1022DS" builds a 32-bit U-Boot.
>  But "make P4080DS" builds a 36-bit U-Boot.  So we've been displaying the
> address map size at boot time in some situations, but not all.  My patch makes
> this standard.

But it's not you who defines what the standard looks like.

> I agree with adding that information to the bdinfo command.  I'm just worried
> about having it available only there.

You will get used to it, and so will your users.

Best regards,

Wolfgang Denk
Wolfgang Denk - Sept. 5, 2011, 2:14 p.m.
Dear Kumar Gala,

In message <6A841E78-5D44-4190-9899-1976234EF955@freescale.com> you wrote:
> 
>  The FSL PPC board ports are not the typical use case.  I view our board
> ports having a few different purposes:
> * Examples for people building their own boards

Especially of this you have additional responsibility not to set bad
examples.

> Having the additional information printed on boot is extremely useful to
> FSL for our board ports for supporting customers.  So my take is the

"extremely useful" is a really big statement.  I don't buy it.

> Any concerns w/that proposal?

I want to clean this up, and I'm extremely unhappy if there are
"examples for people building their own boards" that use excessively
verbose boot messages.

Best regards,

Wolfgang Denk
Wolfgang Denk - Sept. 5, 2011, 2:15 p.m.
Dear Timur Tabi,

In message <4E60DCEC.9090205@freescale.com> you wrote:
> Kumar Gala wrote:
> > Both.  I'm think for your patch we'd add some general config option for extra print info.
> 
> So you want to see this instead:
> 
> /*
>  * Display whether this is a 32-bit build or a 36-bit build.
>  */
> #ifdef CONFIG_DISPLAY_ADDR_SIZE
> #ifdef CONFIG_PHYS_64BIT
> 	puts("ADDR:  36-bit address map\n");
> #else
> 	puts("ADDR:  32-bit address map\n");
> #endif
> #endif

Please dump this completely.

Best regards,

Wolfgang Denk

Patch

diff --git a/arch/powerpc/cpu/mpc85xx/cpu_init.c b/arch/powerpc/cpu/mpc85xx/cpu_init.c
index 27f836c..d691726 100644
--- a/arch/powerpc/cpu/mpc85xx/cpu_init.c
+++ b/arch/powerpc/cpu/mpc85xx/cpu_init.c
@@ -302,6 +302,18 @@  int cpu_init_r(void)
 	sync();
 #endif
 
+	/*
+	 * If we support 36-bit addressing, then display whether this is a
+	 * 32-bit build or a 36-bit build.
+	 */
+#ifdef CONFIG_ENABLE_36BIT_PHYS
+#ifdef CONFIG_PHYS_64BIT
+	puts("ADDR:  36-bit address map\n");
+#else
+	puts("ADDR:  32-bit address map\n");
+#endif
+#endif
+
 	puts ("L2:    ");
 
 #if defined(CONFIG_L2_CACHE)
diff --git a/board/freescale/corenet_ds/corenet_ds.c b/board/freescale/corenet_ds/corenet_ds.c
index b1eecc4..a33c936 100644
--- a/board/freescale/corenet_ds/corenet_ds.c
+++ b/board/freescale/corenet_ds/corenet_ds.c
@@ -62,10 +62,6 @@  int checkboard (void)
 	else
 		printf("invalid setting of SW%u\n", PIXIS_LBMAP_SWITCH);
 
-#ifdef CONFIG_PHYS_64BIT
-	puts("36-bit Addressing\n");
-#endif
-
 	/* Display the RCW, so that no one gets confused as to what RCW
 	 * we're actually using for this boot.
 	 */
diff --git a/board/freescale/mpc8536ds/mpc8536ds.c b/board/freescale/mpc8536ds/mpc8536ds.c
index b292e13..b407f1d 100644
--- a/board/freescale/mpc8536ds/mpc8536ds.c
+++ b/board/freescale/mpc8536ds/mpc8536ds.c
@@ -62,12 +62,7 @@  int checkboard (void)
 	u8 vboot;
 	u8 *pixis_base = (u8 *)PIXIS_BASE;
 
-	puts("Board: MPC8536DS ");
-#ifdef CONFIG_PHYS_64BIT
-	puts("(36-bit addrmap) ");
-#endif
-
-	printf ("Sys ID: 0x%02x, "
+	printf ("Board: MPC8536DS Sys ID: 0x%02x, "
 		"Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
 		in_8(pixis_base + PIXIS_ID), in_8(pixis_base + PIXIS_VER),
 		in_8(pixis_base + PIXIS_PVER));
diff --git a/board/freescale/mpc8572ds/mpc8572ds.c b/board/freescale/mpc8572ds/mpc8572ds.c
index b20299e..38eafe0 100644
--- a/board/freescale/mpc8572ds/mpc8572ds.c
+++ b/board/freescale/mpc8572ds/mpc8572ds.c
@@ -45,11 +45,7 @@  int checkboard (void)
 	u8 vboot;
 	u8 *pixis_base = (u8 *)PIXIS_BASE;
 
-	puts ("Board: MPC8572DS ");
-#ifdef CONFIG_PHYS_64BIT
-	puts ("(36-bit addrmap) ");
-#endif
-	printf ("Sys ID: 0x%02x, "
+	printf ("Board: MPC8572DS Sys ID: 0x%02x, "
 		"Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
 		in_8(pixis_base + PIXIS_ID), in_8(pixis_base + PIXIS_VER),
 		in_8(pixis_base + PIXIS_PVER));
diff --git a/board/freescale/p1010rdb/p1010rdb.c b/board/freescale/p1010rdb/p1010rdb.c
index 03e9da1..7aa2117 100644
--- a/board/freescale/p1010rdb/p1010rdb.c
+++ b/board/freescale/p1010rdb/p1010rdb.c
@@ -165,11 +165,7 @@  int checkboard(void)
 	struct cpu_type *cpu;
 
 	cpu = gd->cpu;
-	printf("Board: %sRDB ", cpu->name);
-#ifdef CONFIG_PHYS_64BIT
-	puts("(36-bit addrmap)");
-#endif
-	puts("\n");
+	printf("Board: %sRDB\n", cpu->name);
 
 	return 0;
 }
diff --git a/board/freescale/p1022ds/p1022ds.c b/board/freescale/p1022ds/p1022ds.c
index 456d9b0..aca30f3 100644
--- a/board/freescale/p1022ds/p1022ds.c
+++ b/board/freescale/p1022ds/p1022ds.c
@@ -56,12 +56,8 @@  int checkboard(void)
 {
 	u8 sw;
 
-	puts("Board: P1022DS ");
-#ifdef CONFIG_PHYS_64BIT
-	puts("(36-bit addrmap) ");
-#endif
-
-	printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
+	printf("Board: P1022DS Sys ID: 0x%02x, "
+	       "Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
 		in_8(&pixis->id), in_8(&pixis->arch), in_8(&pixis->scver));
 
 	sw = in_8(&PIXIS_SW(PIXIS_LBMAP_SWITCH));
diff --git a/board/freescale/p1_p2_rdb/p1_p2_rdb.c b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
index 864b3ce..6418710 100644
--- a/board/freescale/p1_p2_rdb/p1_p2_rdb.c
+++ b/board/freescale/p1_p2_rdb/p1_p2_rdb.c
@@ -110,9 +110,7 @@  int checkboard (void)
 
 	cpu = gd->cpu;
 	printf ("Board: %sRDB Rev%c\n", cpu->name, board_rev);
-#ifdef CONFIG_PHYS_64BIT
-	puts ("(36-bit addrmap) \n");
-#endif
+
 	setbits_be32(&pgpio->gpdir, GPIO_DIR);
 
 /*
diff --git a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
index 4671128..abe087b 100644
--- a/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
+++ b/board/freescale/p1_p2_rdb_pc/p1_p2_rdb_pc.c
@@ -225,13 +225,7 @@  int checkboard(void)
 	ccsr_gur_t *gur = (void *)(CONFIG_SYS_MPC85xx_GUTS_ADDR);
 	u8 in, out, io_config, val;
 
-	printf("Board: %s ", CONFIG_BOARDNAME);
-
-#ifdef CONFIG_PHYS_64BIT
-	puts("(36-bit addrmap) ");
-#endif
-
-	printf("CPLD: V%d.%d PCBA: V%d.0\n",
+	printf("Board: %s CPLD: V%d.%d PCBA: V%d.0\n", CONFIG_BOARDNAME,
 		in_8(&cpld_data->cpld_rev_major) & 0x0F,
 		in_8(&cpld_data->cpld_rev_minor) & 0x0F,
 		in_8(&cpld_data->pcba_rev) & 0x0F);
diff --git a/board/freescale/p2020ds/p2020ds.c b/board/freescale/p2020ds/p2020ds.c
index d3af6cf..e8d31a4 100644
--- a/board/freescale/p2020ds/p2020ds.c
+++ b/board/freescale/p2020ds/p2020ds.c
@@ -61,12 +61,8 @@  int checkboard(void)
 {
 	u8 sw;
 
-	puts("Board: P2020DS ");
-#ifdef CONFIG_PHYS_64BIT
-	puts("(36-bit addrmap) ");
-#endif
-
-	printf("Sys ID: 0x%02x, Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
+	printf("Board: P2020DS Sys ID: 0x%02x, "
+	       "Sys Ver: 0x%02x, FPGA Ver: 0x%02x, ",
 		in_8(&pixis->id), in_8(&pixis->arch), in_8(&pixis->scver));
 
 	sw = in_8(&PIXIS_SW(PIXIS_LBMAP_SWITCH));
diff --git a/board/freescale/p2041rdb/p2041rdb.c b/board/freescale/p2041rdb/p2041rdb.c
index 6ed404f..6e47204 100644
--- a/board/freescale/p2041rdb/p2041rdb.c
+++ b/board/freescale/p2041rdb/p2041rdb.c
@@ -54,10 +54,6 @@  int checkboard(void)
 	sw = CPLD_READ(fbank_sel);
 	printf("vBank: %d\n", sw & 0x1);
 
-#ifdef CONFIG_PHYS_64BIT
-	puts("36-bit Addressing\n");
-#endif
-
 	/*
 	 * Display the RCW, so that no one gets confused as to what RCW
 	 * we're actually using for this boot.