Introduce a new linker flag LDFLAGS_FINAL

From: Haiying Wang <[email protected]>

commit 8aba9dceebb14144e07d19593111ee3a999c37fc Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

breaks the usage of --gc-section to build nand_spl. We still need linker option --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes the --gc-sections to each uboot image.

Dear Haiying.Wang at freescale.com,

Quoted 8 lines · In message <[email protected]> you…

From: Haiying Wang <[email protected]>

commit 8aba9dceebb14144e07d19593111ee3a999c37fc Divides variable of linker flags to LDFLAGS-u-boot and LDFLAGS

breaks the usage of --gc-section to build nand_spl. We still need linker option --gc-section for every uboot image, not only the main one. LDFLAGS_FINAL passes the --gc-sections to each uboot image.

If I understand the intention of the LDFLAGS_u-boot setting corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting.

If you introduce a new LDFLAGS_FINAL instead, then why do we have to keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of the U-Boot image?

[Btw: "final" is probably not a technically correct term for all the use cases I see below.]

Quoted 10 lines

config.mk +1 -0

index 5147c35..caa6221 100644
@@ -205,8 +205,9 @@ endif
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 
 LDFLAGS += $(PLATFORM_LDFLAGS)
+LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
 

config.mk endif · line 210

Quoted 2 lines

config.mk +1 -1

-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?

Are you sure that this change is correct for all affected boards?

How has this change been tested?

config.mk endif · line 211

Quoted 2 lines

config.mk +1 -1

-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)

Arghhh... Here you introduce yet another setting, LDFLAGS_spl ?

This is not mentioned in the commit message. And why do we need it? Isn't LDFLAGS_FINAL enough?

Will I soon see patches to also add LDFLAGS_tpl?

This is becoming a mess. We need to find a simple, clean way to solve this. I'm on the verge of reverting the LDFLAGS_u-boot commit.

Quoted 3 lines

[Btw: "final" is probably not a technically correct term for all the use cases I see below.]

I meant final as compared to partial links, not anything to do with spl versus tpl versus the main image.

Do you have a better wording?

Quoted 8 lines

config.mk endif · line 210

Quoted 5 lines

LDFLAGS += $(PLATFORM_LDFLAGS)

config.mk +2 -1

+LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
 
-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?

Quoted 3 lines

Are you sure that this change is correct for all affected boards?

How has this change been tested?

As I understand it, it has only been limited to PLATFORM_LDFLAGS since the LDFLAGS_u-boot commit. Was that change intentional, and widely tested?

Can you please be more specific? I don't see where "the LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related code. The relevant hunk looks like this:

(quoted diff) +4 -2

@@ -204,9 +204,11 @@ endif
 
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 
-LDFLAGS += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS += $(PLATFORM_LDFLAGS)
+
+LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
 ifneq ($(CONFIG_SYS_TEXT_BASE),)
-LDFLAGS += -Ttext $(CONFIG_SYS_TEXT_BASE)
+LDFLAGS_u-boot += -Ttext $(CONFIG_SYS_TEXT_BASE)
 endif
 
 # Location of a usable BFD library, where we define "usable" as

and this does not make any changes of PLATFORM_LDFLAGS into LDFLAGS or vice versa.

Dear Scott Wood,

Quoted 3 lines · In message <[email protected]> you wrote:

As I understand it, it has only been limited to PLATFORM_LDFLAGS since the LDFLAGS_u-boot commit. Was that change intentional, and widely tested?

Can you please be more specific? I don't see where "the LDFLAGS_u-boot commit" (you mean 8aba9dc ?) would change any related code. The relevant hunk looks like this:

(quoted diff) +0 -0

@@ -204,9 +204,11 @@ endif
 

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

Dear Scott Wood,

Quoted 6 lines · In message <[email protected]> you wrote:

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

Quoted 8 lines

Quoted 6 lines

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of

Dear Scott Wood,

Quoted 9 lines · In message <[email protected]> you wrote:

Quoted 8 lines

Quoted 6 lines

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

Quoted 2 lines

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of

I don;t understand why you contine to talk about "switch to PLATFORM_LDFLAGS in 8aba9dc". There was no such switch - at least I cannot see it.

I see only a switch in your patch. This is why I'm asking.

Quoted 12 lines · On Tue, 1 Feb 2011 21:20:50 +0100 Wolfgang Denk <[email protected]> wrote:

Dear Scott Wood,

Quoted 9 lines · In message <[email protected]> you wrote:

Quoted 8 lines

Quoted 6 lines

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

Quoted 8 lines

Quoted 2 lines

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of

I don;t understand why you contine to talk about "switch to PLATFORM_LDFLAGS in 8aba9dc". There was no such switch - at least I cannot see it.

I see only a switch in your patch. This is why I'm asking.

Before 8aba9dc, the flags for the final link were produced by taking the existing LDFLAGS, and adding:
-Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.

This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link.

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

I don't see any other LDFLAGS changes in board/cpu code, so the distinction between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on current boards. However, the patch appears to be intended to support platform linker flags that need to be used during partial link, which would involve board/cpu additions to LDFLAGS. This change would break that only if those options need to be used for partial link *only*, and cannot be used in the final link. In such a case I'd suggest using something like LDFLAGS_PARTIAL to make this explicit. But I'd be surprised if that were actually the case.

If you're looking to cut down on the number of variables, it's not clear to me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to LDFLAGS.

-Scott

Before 8aba9dc, the flags for the final link were produced by taking the existing LDFLAGS, and adding:
-Bstatic -T <linkerscript> $(PLATFORM_LDFLAGS) -Ttext <addr>.

This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link.

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

I don't see any other LDFLAGS changes in board/cpu code, so the distinction between using LDFLAGS and PLATFORM_LDFLAGS should have no other impact on current boards. However, the patch appears to be intended to support platform linker flags that need to be used during partial link, which would involve board/cpu additions to LDFLAGS. This change would break that only if those options need to be used for partial link *only*, and cannot be used in the final link. In such a case I'd suggest using something like LDFLAGS_PARTIAL to make this explicit. But I'd be surprised if that were actually the case.

If you're looking to cut down on the number of variables, it's not clear to me what PLATFORM_LDFLAGS is supposed to mean distinct from adding to LDFLAGS.

so commit 8aba9dc is not something made for fun, but to fix real bugs people were seeing while building with bi-endian toolchains (arm/superh/mips/probably others), or bi-abi toolchains (blackfin/arm/probably others).

Quoted 5 lines

This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link.

Quoted 4 lines

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

err, i dont think this is correct. LDFLAGS is no longer the *only* source for the final link. if you look at the actual target, you'll see it using $(LDFLAGS) $(LDFLAGS_$(@F)).

Quoted 11 lines · On Tue, 15 Feb 2011 04:02:44 -0500 Mike Frysinger wrote:

Quoted 10 lines

This included anything that cpu/board code added to LDFLAGS -- some architectures added --gc-sections, x86 added --cref, etc. Since the above flags are added to LDFLAGS, rather than replacing them, these flags got used in the final link.

Commit 8aba9dc introduces LDFLAGS_u-boot, so that LDFLAGS is no longer the source for the flags for the final link. It generates LDFLAGS_u-boot using PLATFORM_LDFLAGS, not LDFLAGS. It converts most of the board/cpu updates to LDFLAGS into LDFLAGS_u-boot, but it missed --cref.

Quoted 3 lines

err, i dont think this is correct. LDFLAGS is no longer the *only* source for the final link. if you look at the actual target, you'll see it using $(LDFLAGS) $(LDFLAGS_$(@F)).

Ah. So why is PLATFORM_LDFLAGS added into both LDFLAGS and LDFLAGS_u-boot? :-P

Quoted 11 lines · On Tue, 1 Feb 2011 20:32:29 +0100 Wolfgang Denk <[email protected]> wrote:

Dear Scott Wood,

Quoted 6 lines · In message <[email protected]> you wrote:

Prior to the introduction of LDFLAGS_u-boot, was LDFLAGS not what was used? So before, anything that board/cpu code adds directly to LDFLAGS (maybe they're supposed to use PLATFORM_LDFLAGS, but not all do) was used in the final link. After 8aba9dc, only things in PLATFORM_LDFLAGS plus -Bstatic and -T are used in the final link.

And this is correct for all boards?

By "this" do you mean the switch to PLATFORM_LDFLAGS in 8aba9dc, or the switch back to LDFLAGS? It's not obvious to me that the dropping of board/cpu modifications to LDFLAGS except during partial link was an intentional change, or a correct one for all boards.

The only case I see where it makes any difference at all is arch/i386, which does LDFLAGS += --cref. From the description of --cref in the linker manual, it probably actually belongs in LDFLAGS_FINAL, though I'm not sure if it's harmless to include it in partial link or not. Currently, with 8aba9dc, it's included *only* in partial link.

It's also not clear to me what this option has to do with i386... it looks like an arch-neutral debugging feature that doesn't affect the actual u-boot image at all (the output goes into the map file).

If I understand the intention of the LDFLAGS_u-boot setting corrrectly, then you would have to add a "LDFLAGS_nand_spl" setting.

If you introduce a new LDFLAGS_FINAL instead, then why do we have to keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of the U-Boot image?

[Btw: "final" is probably not a technically correct term for all the use cases I see below.]

...

Quoted 7 lines

config.mk +0 -0

index 5147c35..caa6221 100644
@@ -205,8 +205,9 @@ endif
 AFLAGS := $(AFLAGS_DEBUG) -D__ASSEMBLY__ $(CPPFLAGS)
 

config.mk endif · line 210

Quoted 5 lines

config.mk +2 -1

 LDFLAGS += $(PLATFORM_LDFLAGS)
+LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
 
-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?

Are you sure that this change is correct for all affected boards?

How has this change been tested?

config.mk endif · line 211

Quoted 3 lines

config.mk +1 -1

-LDFLAGS	= -Bstatic -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(PLATFORM_LDFLAGS)
+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)

Arghhh... Here you introduce yet another setting, LDFLAGS_spl ?

This is not mentioned in the commit message. And why do we need it? Isn't LDFLAGS_FINAL enough?

Will I soon see patches to also add LDFLAGS_tpl?

This is becoming a mess. We need to find a simple, clean way to solve this. I'm on the verge of reverting the LDFLAGS_u-boot commit.

Quoted 4 lines

If you introduce a new LDFLAGS_FINAL instead, then why do we have to keep LDFLAGS_u-boot - isn't LDFLAGS_u-boot also for "final" linking of the U-Boot image?

LDFLAGS_FINAL does not provide the whole set of linker options to U-Boot image, so it does not replace the LDFLAGS_u-boot, in patch:

Quoted 7 lines

config.mk endif · line 210

Quoted 5 lines

LDFLAGS += $(PLATFORM_LDFLAGS)

config.mk +2 -1

+LDFLAGS_FINAL += -Bstatic $(LDFLAGS)
 
-LDFLAGS_u-boot += -Bstatic -T $(obj)u-boot.lds $(PLATFORM_LDFLAGS)
+LDFLAGS_u-boot += -T $(obj)u-boot.lds $(LDFLAGS_FINAL)

Is it intentional that you change PLATFORM_LDFLAGS into LDFLAGS here?

Yes. it LDFLAGS_FINAL here includes "-Bstatic $(PLATFORM_LDFLAGS)".

Quoted 1 line

Are you sure that this change is correct for all affected boards?

Can not 100% sure because I can not test all the affected boards.

Quoted 1 line

How has this change been tested?

I only can test powerpc by MAKEALL.

Quoted 3 lines

Quoted 1 line

+LDFLAGS_spl := -T $(nandobj)u-boot.lds -Ttext $(CONFIG_SYS_TEXT_BASE) $(LDFLAGS_FINAL)

Arghhh... Here you introduce yet another setting, LDFLAGS_spl ?

This is an intentional name change. LDFLAGS_spl is used here as LDFLAGS_u-boot, but for nand spl linkage. Actually it is not a new FLAGS, just add *_spl* here so that it can be differed from the LDFlAGS in toplevel config.mk.

Quoted 2 lines

This is not mentioned in the commit message. And why do we need it? Isn't LDFLAGS_FINAL enough?

As said, it is not a new flag, just a name change.

Quoted 1 line

Will I soon see patches to also add LDFLAGS_tpl?

Yes, in patch 3/6.

I did run "./MAKEALL powerpc" for all ppc board, the System.map and u-boot.map keep exactly the same before and after applying the LDFLAGS_FINAL patch. Please find the attached two txt files and System.map and u-boot.map which are the results of MAKEALL. Do you think

it is ok to apply this patch, if you are ok with the name _FINAL?

Dear Haiying Wang,

Quoted 5 lines · In message <1297878184.1977.18.camel@haiying-laptop> you wrote:

I did run "./MAKEALL powerpc" for all ppc board, the System.map and u-boot.map keep exactly the same before and after applying the LDFLAGS_FINAL patch. Please find the attached two txt files and System.map and u-boot.map which are the results of MAKEALL. Do you think

I'm surrised that you send just one pair of these files. Does that mean that you did the compare only after the full MAKEALL run, i. e. just on the last result, for the last board?

We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this?

Quoted 1 line

it is ok to apply this patch, if you are ok with the name _FINAL?

Others appear to be happy with it, and I don't have a better proposal, so let's use this _FINAL name.

Quoted 5 lines

We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this?

Quoted 1 line

it is ok to apply this patch, if you are ok with the name _FINAL?

Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?

Quoted 9 lines · Haiying Wang

Quoted 5 lines

We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this?

Quoted 1 line

it is ok to apply this patch, if you are ok with the name _FINAL?

Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?

I usually do this on the fly using shell scripting capabilities, i.e. something like this (copying some shell functions from MAKEALL):

-----------------------------------------------------------------------
boards_by_field()

{
        awk \
                -v field="$1" \
                -v select="$2" \
                '($1 !~ /^#/ && $field == select) { print $1 }' \
                boards.cfg
}

boards_by_arch() { boards_by_field 2 "$@" ; }

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cp System.map System.map.${board}.unpatched
cp u-boot.map u-boot.map.${board}.unpatched
done

...apply patch...

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cmp System.map.${board}.unpatched System.map || diff -u System.map.${board}.unpatched System.map >System.map.${board}.diff cmp u-boot.map.${board}.unpatched u-boot.map || diff -u u-boot.map.${board}.unpatched u-boot.map >u-boot.map.${board}.diff done

Quoted 3 lines

I usually do this on the fly using shell scripting capabilities, i.e. something like this (copying some shell functions from MAKEALL):

this is is generally useful, perhaps MAKEALL should grow a flag to back up the generated files with board-qualified names like the log files ...

Dear Haiying Wang,

Quoted 6 lines · In message <1297881643.1977.28.camel@haiying-laptop> you wrote:

Quoted 5 lines

We have some 524 PowerPC configurations in boards.cfg, and the compare must be done for _all_ off these, i. e. there are 2 x 524 pairs of files to be compared. Did you really do this?

Quoted 1 line

it is ok to apply this patch, if you are ok with the name _FINAL?

Sorry, I did not get the 2x254 pairs of System.map and u-boot.map. Running "MAKEALL powerpc" only left the last pair. Could you please show me how I can keep the former 523 pairs?

I usually do this on the fly using shell scripting capabilities, i.e. something like this (copying some shell functions from MAKEALL):

-----------------------------------------------------------------------
boards_by_field()

{
        awk \
                -v field="$1" \
                -v select="$2" \
                '($1 !~ /^#/ && $field == select) { print $1 }' \
                boards.cfg
}

boards_by_arch() { boards_by_field 2 "$@" ; }

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board
cp System.map System.map.${board}.unpatched
cp u-boot.map u-boot.map.${board}.unpatched
done

...apply patch...

for board in $(boards_by_arch powerpc) ; do
./MAKEALL $board

cmp System.map.${board}.unpatched System.map || diff -u System.map.${board}.unpatched System.map >System.map.${board}.diff
cmp u-boot.map.${board}.unpatched u-boot.map || diff -u u-boot.map.${board}.unpatched u-boot.map >u-boot.map.${board}.diff

done

less *.diff
-----------------------------------------------------------------------

Quoted 1 line

Your scripts works fine. Now I only get one pair of diff which are System.map.mpc7448hpc2.diff u-boot.map.mpc7448hpc2.diff, because mpc7448hpc2 failed to build:
"
Configuring for mpc7448hpc2 board...
cc1: error: AltiVec and E500 instructions cannot coexist
cc1: error: AltiVec and E500 instructions cannot coexist lib/asm-offsets.c:1: error: AltiVec and E500 instructions cannot coexist
make: *** [lib/asm-offsets.s] Error 1
make: *** Waiting for unfinished jobs....

--------------------- SUMMARY ---------------------------- Boards compiled: 1
Boards with warnings or errors: 1 ( mpc7448hpc2 )
----------------------------------------------------------
".

Other than that, I think all the System.map and u-boot.map keep the same before and after applying the patch.

Quoted 11 lines

Your scripts works fine. Now I only get one pair of diff which are System.map.mpc7448hpc2.diff u-boot.map.mpc7448hpc2.diff, because mpc7448hpc2 failed to build:
"
Configuring for mpc7448hpc2 board...
cc1: error: AltiVec and E500 instructions cannot coexist
cc1: error: AltiVec and E500 instructions cannot coexist lib/asm-offsets.c:1: error: AltiVec and E500 instructions cannot coexist
make: *** [lib/asm-offsets.s] Error 1
make: *** Waiting for unfinished jobs....

Sorry, I ignored some other info just now. Not only 7448 but also some other boards failed to build, you can get the failed info from the beforepatch.txt and afterpatch.txt I sent yesterday. The final result should be:

haiying at haiying-laptop:~/Opensource/Denx/u-boot$ ls -s *.diff

0 System.map.ESTEEM192E.diff         0 System.map.P2020DS.diff
0 System.map.ETX094.diff             0 System.map.sbc8641d.diff
0 System.map.LANTEC.diff             0 System.map.SPD823TS.diff
0 System.map.mpc7448hpc2.diff        0 System.map.xpedite517x.diff
0 System.map.MPC8610HPCD.diff        0 u-boot.map.mpc7448hpc2.diff
0 System.map.MPC8641HPCN_36BIT.diff  0 u-boot.map.MPC8610HPCD.diff
0 System.map.MPC8641HPCN.diff        0 u-boot.map.MPC8641HPCN_36BIT.diff
0 System.map.mpq101.diff             0 u-boot.map.MPC8641HPCN.diff
0 System.map.P2020DS_36BIT.diff      0 u-boot.map.sbc8641d.diff
0 System.map.P2020DS_DDR2.diff       0 u-boot.map.xpedite517x.diff

The above boards failed to build thus the diff files were generated but the contents are all 0.

All the other boards should not have difference in System.map/u-boot.map before and after applying the LDFLAGS_FINAL patch.