Skip to contentSkip to conversation

mpc83xx: Size optimization of start.S

PATCH New Ron Madrid 4 participants 10 messages Dec 12, 2008 – Jan 22, 2009

lore
Share & tools
lore

Ron Madrid

author
#0 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized. This patch moves a few functions into this part of the image. This will create a greater number of *available* bytes that can be used by board specific code in NAND builds and will decrease the size of the assembled code in other builds.

---
 cpu/mpc83xx/start.S |   77 ++++++++++++++++++++++++++-------------------------
 1 files changed, 39 insertions(+), 38 deletions(-)
cpu/mpc83xx/start.S +39 -38
index cd566b2..b040e3b 100644
@@ -108,6 +108,45 @@ version_string:
 	.ascii " (", __DATE__, " - ", __TIME__, ")"
 	.ascii " ", CONFIG_IDENT_STRING, "\0"
 
+	.align 2
+
+	.globl enable_addr_trans
+enable_addr_trans:
+	/* enable address translation */
+	mfmsr	r5
+	ori	r5, r5, (MSR_IR | MSR_DR)
+	mtmsr	r5
+	isync
+	blr
+
+	.globl disable_addr_trans
+disable_addr_trans:
+	/* disable address translation */
+	mflr	r4
+	mfmsr	r3
+	andi.	r0, r3, (MSR_IR | MSR_DR)
+	beqlr
+	andc	r3, r3, r0
+	mtspr	SRR0, r4
+	mtspr	SRR1, r3
+	rfi
+
+	.globl get_pvr
+get_pvr:
+	mfspr	r3, PVR
+	blr
+
+	.globl	ppcDWstore
+ppcDWstore:
+	lfd	1, 0(r4)
+	stfd	1, 0(r3)
+	blr
+
+	.globl	ppcDWload
+ppcDWload:
+	lfd	1, 0(r3)
+	stfd	1, 0(r4)
+	blr
 
 #ifndef CONFIG_DEFAULT_IMMR
 #error CONFIG_DEFAULT_IMMR must be defined
@@ -697,27 +736,6 @@ setup_bats:
 
 	blr
 
-	.globl enable_addr_trans
-enable_addr_trans:
-	/* enable address translation */
-	mfmsr	r5
-	ori	r5, r5, (MSR_IR | MSR_DR)
-	mtmsr	r5
-	isync
-	blr
-
-	.globl disable_addr_trans
-disable_addr_trans:
-	/* disable address translation */
-	mflr	r4
-	mfmsr	r3
-	andi.	r0, r3, (MSR_IR | MSR_DR)
-	beqlr
-	andc	r3, r3, r0
-	mtspr	SRR0, r4
-	mtspr	SRR1, r3
-	rfi
-
 /* Cache functions.
  *
  * Note: requires that all cache bits in
@@ -795,23 +813,6 @@ flush_dcache:
 	b	1b
 2:	blr
 
-	.globl get_pvr
-get_pvr:
-	mfspr	r3, PVR
-	blr
-
-	.globl	ppcDWstore
-ppcDWstore:
-	lfd	1, 0(r4)
-	stfd	1, 0(r3)
-	blr
-
-	.globl	ppcDWload
-ppcDWload:
-	lfd	1, 0(r3)
-	stfd	1, 0(r4)
-	blr
-
 /*-------------------------------------------------------------------*/
 
 /*
Signature · 1 line
1.5.5.1
#1 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Hi Ron,

Quoted 2 lines · Ron Madrid

Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized.

Hmmm, are you sure? What if someone designs a board, where the processor shall load its reset configuration from a local bus EEPROM, e.g. the same NOR-Flash containing the U-Boot image (CFG_RESET_SOURCE[0:2] = 000b?

Or did I misunderstand something?

Kind regards,
Jens

#2 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Quoted 6 lines · Jens Gehrlein

Hi Ron,

Quoted 2 lines · Ron Madrid

Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized.

Quoted 6 lines

Hmmm, are you sure? What if someone designs a board, where the processor shall load its reset configuration from a local bus EEPROM, e.g. the same NOR-Flash containing the U-Boot image (CFG_RESET_SOURCE[0:2] = 000b?

Or did I misunderstand something?

That's covered by the _HRCW_TABLE_ENTRY lines earlier in the file.

-Scott

#3 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Hi Scott,

Quoted 6 lines · Scott Wood
Quoted 5 lines · Jens Gehrlein

Hi Ron,

Quoted 2 lines · Ron Madrid

Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized.

Quoted 8 lines
Quoted 6 lines

Hmmm, are you sure? What if someone designs a board, where the processor shall load its reset configuration from a local bus EEPROM, e.g. the same NOR-Flash containing the U-Boot image (CFG_RESET_SOURCE[0:2] = 000b?

Or did I misunderstand something?

That's covered by the _HRCW_TABLE_ENTRY lines earlier in the file.

I see. I understood Ron's comment as "first 100 hex bytes". Thanks for the hint, Scott.

Kind regards,
Jens

author
#4 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

In reply to Ron Madrid

I haven't received any communication about this patch in a while. Is is still being looked at or did it slip through the cracks? Or did I miss an email?

Let me know.

Ron

Quoted 21 lines · Ron Madrid

From: Ron Madrid <[email protected]>
Subject: [PATCH] mpc83xx: Size optimization of start.S
To: u-boot at lists.denx.de
Cc: "Ron Madrid" <[email protected]>
Date: Friday, December 12, 2008, 1:12 PM Currently there are in excess of 100 bytes located at the beginning of the image
built by start.S that are not being utilized. This patch moves a few functions
into this part of the image. This will create a greater number of *available*
bytes that can be used by board specific code in NAND builds and will decrease
the size of the assembled code in other builds.

---
 cpu/mpc83xx/start.S |   77
++++++++++++++++++++++++++-------------------------
 1 files changed, 39 insertions(+), 38 deletions(-)
#5 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

In reply to Ron Madrid
Quoted 8 lines · On Fri, 12 Dec 2008 13:12:45 -0800 Ron Madrid <[email protected]> wrote:

Currently there are in excess of 100 bytes located at the beginning of the image built by start.S that are not being utilized. This patch moves a few functions into this part of the image. This will create a greater number of *available* bytes that can be used by board specific code in NAND builds and will decrease the size of the assembled code in other builds.

---

applied to u-boot-mpc83xx next.

Thanks, and sorry for the delay,

Kim

author
#6 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

No worries. With the holidays and all I figured that it was just delayed.

Since my new board patch is dependent on this being applied is it possible to now resubmit my new board patch?

Thanks.

Ron

Quoted 27 lines · Kim Phillips

From: Kim Phillips <[email protected]>
Subject: Re: [U-Boot] [PATCH] mpc83xx: Size optimization of start.S
To: "Ron Madrid" <[email protected]>
Cc: u-boot at lists.denx.de
Date: Wednesday, January 21, 2009, 4:55 PM

Quoted 1 line · On Fri, 12 Dec 2008 13:12:45 -0800 Ron Madrid <[email protected]> wrote:

Currently there are in excess of 100 bytes located at

the beginning of the image

Quoted 1 line

built by start.S that are not being utilized. This

patch moves a few functions

Quoted 1 line

into this part of the image. This will create a

greater number of *available*

Quoted 1 line

bytes that can be used by board specific code in NAND

builds and will decrease

Quoted 3 lines

the size of the assembled code in other builds.

Signed-off-by Ron Madrid

<[email protected]>

Quoted 1 line

---

applied to u-boot-mpc83xx next.

Thanks, and sorry for the delay,

Kim

#7 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Quoted 1 line · On Thu, 22 Jan 2009 10:00:56 -0800 (PST) Ron Madrid <[email protected]>…

Since my new board patch is dependent on this being applied is it possible to now resubmit my new board patch?

I thought you'd never ask :)

please base it on u-boot-mpc83xx next.

Kim

author
#8 lore raw

PATCH 1/1 mpc83xx: Size optimization of start.S

Should this go to the main u-boot mail list or should I send it somewhere else?

Ron

Quoted 16 lines · Kim Phillips

From: Kim Phillips <[email protected]>
Subject: Re: [U-Boot] [PATCH] mpc83xx: Size optimization of start.S
To: ron_madrid at sbcglobal.net
Cc: u-boot at lists.denx.de
Date: Thursday, January 22, 2009, 10:37 AM

Quoted 1 line · On Thu, 22 Jan 2009 10:00:56 -0800 (PST) Ron Madrid <[email protected]>…

Since my new board patch is dependent on this being

applied is it possible to now resubmit my new board patch?

I thought you'd never ask :)

please base it on u-boot-mpc83xx next.

Kim