| Message ID | 1329805072-9572-7-git-send-email-sjg@chromium.org |
|---|---|
| State | Superseded, archived |
| Delegated to: | Albert ARIBAUD |
| Headers | show |
Hi Simon, Le 21/02/2012 07:17, Simon Glass a écrit : > Most ARM CPUs use a very similar link script. This adds a basic > script that can be used by most CPUs. > > Two new symbols are introduced which are intended to eventually be > defined on all architectures to make things easier for generic relocation > and reduce special-case code for each architecture: > > __text_start is the start of the text area (equivalent to the existing > _start on ARM). It marks the start of the region which must be copied > to a new location during relocation. Please name it _image_copy_start, not __text_start > __image_copy_end is the end of the region which must be copied to a new > location during relocation. It is normally equal to the start of the BSS > region, but this can vary in some cases (SPL?). Making this an explicit > symbol on its own removes any ambiguity and permits common code to always > do the right thing. > > This new script makes use of CPUDIR, now defined by both Makefile and > spl/Makefile, to find the directory containing the start.o object file, > which is always placed first in the image. > > To permit MMU setup prior to relocation (as used by pxa) we add an area > to the link script which contains space for this. This is taken > from commit 7f4cfcf. CPUs can put the contents in there using their > start.S file. BTW, shouldn't that area be 16KB-aligned? > > Signed-off-by: Simon Glass<sjg@chromium.org> > --- > Changes in v3: > - Add more comments in the commit message > - Add section for MMU area, as required by pxa > > arch/arm/cpu/u-boot.lds | 91 +++++++++++++++++++++++++++++++++++++++++++++++ > 1 files changed, 91 insertions(+), 0 deletions(-) > create mode 100644 arch/arm/cpu/u-boot.lds > > diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds > new file mode 100644 > index 0000000..7a859fc > --- /dev/null > +++ b/arch/arm/cpu/u-boot.lds > @@ -0,0 +1,91 @@ > +/* > + * Copyright (c) 2004-2008 Texas Instruments > + * > + * (C) Copyright 2002 > + * Gary Jennejohn, DENX Software Engineering,<garyj@denx.de> > + * > + * See file CREDITS for list of people who contributed to this > + * project. > + * > + * This program is free software; you can redistribute it and/or > + * modify it under the terms of the GNU General Public License as > + * published by the Free Software Foundation; either version 2 of > + * the License, or (at your option) any later version. > + * > + * This program is distributed in the hope that it will be useful, > + * but WITHOUT ANY WARRANTY; without even the implied warranty of > + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > + * GNU General Public License for more details. > + * > + * You should have received a copy of the GNU General Public License > + * along with this program; if not, write to the Free Software > + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > + * MA 02111-1307 USA > + */ > + > +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") > +OUTPUT_ARCH(arm) > +ENTRY(_start) > +SECTIONS > +{ > + . = 0x00000000; > + > + . = ALIGN(4); > + .text : > + { > + __text_start = .; > + CPUDIR/start.o (.text) > + *(.text) > + } > + > + . = ALIGN(4); > + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } > + > + . = ALIGN(4); > + .data : { > + *(.data) > + } > + > + . = ALIGN(4); > + > + . = .; > + __u_boot_cmd_start = .; > + .u_boot_cmd : { *(.u_boot_cmd) } > + __u_boot_cmd_end = .; > + > + . = ALIGN(4); This "ALIGN(4)" is what upsets my edminiv2 build and makes it not binary-identical. It is not in the current arm926ejs liner script. I will check if adding it to the current arm926ejs script produces a working and binary-identical u-boot. > + __image_copy_end = .; > + > + .rel.dyn : { > + __rel_dyn_start = .; > + *(.rel*) > + __rel_dyn_end = .; > + } > + > + .dynsym : { > + __dynsym_start = .; > + *(.dynsym) > + } > + > + _end = .; Below is what I assume to be the reservation for MMU. > + . = ALIGN(4096); > + > + .mmutable : { > + *(.mmutable) > + } ... and I don't like it at all, more so if it is going to be actually 16 KB, because it seems to me we're wasting memory and creating a hole in the middle of our in-RAM binary, and I'm not sure we need to do it here in the first place. Do we need to have that MMU region mapped over DDR? And if so, do we need to have it mapped in the middle of u-boot? Plus you're placing it after .dynsym and .rel.dyn, but possibly overlaid with .bss. Normally this area should have gone by the time we get to use BSS, but assumption is the mother of all screw-ups. > + .bss __rel_dyn_start (OVERLAY) : { > + __bss_start = .; > + *(.bss) > + . = ALIGN(4); > + __bss_end__ = .; > + } > + > + /DISCARD/ : { *(.dynstr*) } > + /DISCARD/ : { *(.dynamic*) } > + /DISCARD/ : { *(.plt*) } > + /DISCARD/ : { *(.interp*) } > + /DISCARD/ : { *(.gnu*) } > +} Amicalement,
Hi again Simon, Le 21/02/2012 14:11, Albert ARIBAUD a écrit : >> Two new symbols are introduced which are intended to eventually be >> defined on all architectures to make things easier for generic relocation >> and reduce special-case code for each architecture: >> >> __text_start is the start of the text area (equivalent to the existing >> _start on ARM). It marks the start of the region which must be copied >> to a new location during relocation. > > Please name it _image_copy_start, not __text_start Also, I realize this introduces two symbols which are not used within the same patch set. Amicalement,
Hi Albert, On Tue, Feb 21, 2012 at 5:11 AM, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hi Simon, > > Le 21/02/2012 07:17, Simon Glass a écrit : > >> Most ARM CPUs use a very similar link script. This adds a basic >> script that can be used by most CPUs. >> >> Two new symbols are introduced which are intended to eventually be >> defined on all architectures to make things easier for generic relocation >> and reduce special-case code for each architecture: >> >> __text_start is the start of the text area (equivalent to the existing >> _start on ARM). It marks the start of the region which must be copied >> to a new location during relocation. > > > Please name it _image_copy_start, not __text_start OK will do > > >> __image_copy_end is the end of the region which must be copied to a new >> location during relocation. It is normally equal to the start of the BSS >> region, but this can vary in some cases (SPL?). Making this an explicit >> symbol on its own removes any ambiguity and permits common code to always >> do the right thing. >> >> This new script makes use of CPUDIR, now defined by both Makefile and >> spl/Makefile, to find the directory containing the start.o object file, >> which is always placed first in the image. >> >> To permit MMU setup prior to relocation (as used by pxa) we add an area >> to the link script which contains space for this. This is taken >> from commit 7f4cfcf. CPUs can put the contents in there using their >> start.S file. BTW, shouldn't that area be 16KB-aligned? >> >> Signed-off-by: Simon Glass<sjg@chromium.org> >> --- >> Changes in v3: >> - Add more comments in the commit message >> - Add section for MMU area, as required by pxa >> >> arch/arm/cpu/u-boot.lds | 91 >> +++++++++++++++++++++++++++++++++++++++++++++++ >> 1 files changed, 91 insertions(+), 0 deletions(-) >> create mode 100644 arch/arm/cpu/u-boot.lds >> >> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds >> new file mode 100644 >> index 0000000..7a859fc >> --- /dev/null >> +++ b/arch/arm/cpu/u-boot.lds >> @@ -0,0 +1,91 @@ >> +/* >> + * Copyright (c) 2004-2008 Texas Instruments >> + * >> + * (C) Copyright 2002 >> + * Gary Jennejohn, DENX Software Engineering,<garyj@denx.de> >> + * >> + * See file CREDITS for list of people who contributed to this >> + * project. >> + * >> + * This program is free software; you can redistribute it and/or >> + * modify it under the terms of the GNU General Public License as >> + * published by the Free Software Foundation; either version 2 of >> + * the License, or (at your option) any later version. >> + * >> + * This program is distributed in the hope that it will be useful, >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> + * GNU General Public License for more details. >> + * >> + * You should have received a copy of the GNU General Public License >> + * along with this program; if not, write to the Free Software >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, >> + * MA 02111-1307 USA >> + */ >> + >> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") >> +OUTPUT_ARCH(arm) >> +ENTRY(_start) >> +SECTIONS >> +{ >> + . = 0x00000000; >> + >> + . = ALIGN(4); >> + .text : >> + { >> + __text_start = .; >> + CPUDIR/start.o (.text) >> + *(.text) >> + } >> + >> + . = ALIGN(4); >> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } >> + >> + . = ALIGN(4); >> + .data : { >> + *(.data) >> + } >> + >> + . = ALIGN(4); >> + >> + . = .; >> + __u_boot_cmd_start = .; >> + .u_boot_cmd : { *(.u_boot_cmd) } >> + __u_boot_cmd_end = .; >> + >> + . = ALIGN(4); > > > This "ALIGN(4)" is what upsets my edminiv2 build and makes it not > binary-identical. It is not in the current arm926ejs liner script. I will > check if adding it to the current arm926ejs script produces a working and > binary-identical u-boot. OK, but realistically we copy a word at a time (at least) and the .rel.dyn region is going to be word-aligned I think. All we are doing here is making sure that the image ends on a word boundary, which seems reasonable to me. In other words, I would like the __image_copy_start and __image_copy_end symbols to be word-aligned. > > >> + __image_copy_end = .; >> + >> + .rel.dyn : { >> + __rel_dyn_start = .; >> + *(.rel*) >> + __rel_dyn_end = .; >> + } >> + >> + .dynsym : { >> + __dynsym_start = .; >> + *(.dynsym) >> + } >> + >> + _end = .; > > > Below is what I assume to be the reservation for MMU. > > >> + . = ALIGN(4096); >> + >> + .mmutable : { >> + *(.mmutable) >> + } > > > ... and I don't like it at all, more so if it is going to be actually 16 KB, > because it seems to me we're wasting memory and creating a hole in the > middle of our in-RAM binary, and I'm not sure we need to do it here in the > first place. Do we need to have that MMU region mapped over DDR? And if so, > do we need to have it mapped in the middle of u-boot? Plus you're placing it > after .dynsym and .rel.dyn, but possibly overlaid with .bss. Normally this > area should have gone by the time we get to use BSS, but assumption is the > mother of all screw-ups. Yes it will be 16KB, although of course only if it exists. At present it is only used for pxa so including it here allows pxa boards to build. The hole is not in the middle of the binary, but at the end. The BSS may overlay it if large enough, but that doesn't take affect until after relocation. I'm not thrilled with it either, but it does allow us to have an option to set up the MMU table at compile time for those that need it. Having thought about it a bit more I feel that we should be able to set this up at run-time instead, but still, it is needed at present for pxa, so... I have question also, for Marek. Should this be 16KB aligned, since ARM needs this I think. The alignment is currently provided by pxa's start.S but we might as well be explicit here I think. > > >> + .bss __rel_dyn_start (OVERLAY) : { >> + __bss_start = .; >> + *(.bss) >> + . = ALIGN(4); >> + __bss_end__ = .; >> + } >> + >> + /DISCARD/ : { *(.dynstr*) } >> + /DISCARD/ : { *(.dynamic*) } >> + /DISCARD/ : { *(.plt*) } >> + /DISCARD/ : { *(.interp*) } >> + /DISCARD/ : { *(.gnu*) } >> +} > > > Amicalement, > -- > Albert. Regards, Simon
Hi Simon, Le 21/02/2012 18:02, Simon Glass a écrit : >>> + . = ALIGN(4); >> >> >> This "ALIGN(4)" is what upsets my edminiv2 build and makes it not >> binary-identical. It is not in the current arm926ejs liner script. I will >> check if adding it to the current arm926ejs script produces a working and >> binary-identical u-boot. > > OK, but realistically we copy a word at a time (at least) and the > .rel.dyn region is going to be word-aligned I think. All we are doing > here is making sure that the image ends on a word boundary, which > seems reasonable to me. > > In other words, I would like the __image_copy_start and > __image_copy_end symbols to be word-aligned. I understand the requirement and agree to it -- only, it seems to me it is already fulfilled in the current lds files, so I still fail to see what breaks 'near binary identity'. Amicalement,
Hi Albert, On Tue, Feb 21, 2012 at 11:52 AM, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hi Simon, > > Le 21/02/2012 18:02, Simon Glass a écrit : > > >>>> + . = ALIGN(4); >>> >>> >>> >>> This "ALIGN(4)" is what upsets my edminiv2 build and makes it not >>> binary-identical. It is not in the current arm926ejs liner script. I will >>> check if adding it to the current arm926ejs script produces a working and >>> binary-identical u-boot. >> >> >> OK, but realistically we copy a word at a time (at least) and the >> .rel.dyn region is going to be word-aligned I think. All we are doing >> here is making sure that the image ends on a word boundary, which >> seems reasonable to me. >> >> In other words, I would like the __image_copy_start and >> __image_copy_end symbols to be word-aligned. > > > I understand the requirement and agree to it -- only, it seems to me it is > already fulfilled in the current lds files, so I still fail to see what > breaks 'near binary identity'. If we add any symbols or change the value of any of them, then the binary file may change. You can see the differences by doing something like: armv7a-cros-linux-gnueabi-objdump -b binary -m arm -D u-boot.bin on each file (but I guess you know that). > > Amicalement, > -- > Albert. Regards, Simon
> Hi Albert, > > On Tue, Feb 21, 2012 at 5:11 AM, Albert ARIBAUD > > <albert.u.boot@aribaud.net> wrote: > > Hi Simon, > > > > Le 21/02/2012 07:17, Simon Glass a écrit : > >> Most ARM CPUs use a very similar link script. This adds a basic > >> script that can be used by most CPUs. > >> > >> Two new symbols are introduced which are intended to eventually be > >> defined on all architectures to make things easier for generic > >> relocation and reduce special-case code for each architecture: > >> > >> __text_start is the start of the text area (equivalent to the existing > >> _start on ARM). It marks the start of the region which must be copied > >> to a new location during relocation. > > > > Please name it _image_copy_start, not __text_start > > OK will do > > >> __image_copy_end is the end of the region which must be copied to a new > >> location during relocation. It is normally equal to the start of the BSS > >> region, but this can vary in some cases (SPL?). Making this an explicit > >> symbol on its own removes any ambiguity and permits common code to > >> always do the right thing. > >> > >> This new script makes use of CPUDIR, now defined by both Makefile and > >> spl/Makefile, to find the directory containing the start.o object file, > >> which is always placed first in the image. > >> > >> To permit MMU setup prior to relocation (as used by pxa) we add an area > >> to the link script which contains space for this. This is taken > >> from commit 7f4cfcf. CPUs can put the contents in there using their > >> start.S file. BTW, shouldn't that area be 16KB-aligned? > >> > >> Signed-off-by: Simon Glass<sjg@chromium.org> > >> --- > >> Changes in v3: > >> - Add more comments in the commit message > >> - Add section for MMU area, as required by pxa > >> > >> arch/arm/cpu/u-boot.lds | 91 > >> +++++++++++++++++++++++++++++++++++++++++++++++ > >> 1 files changed, 91 insertions(+), 0 deletions(-) > >> create mode 100644 arch/arm/cpu/u-boot.lds > >> > >> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds > >> new file mode 100644 > >> index 0000000..7a859fc > >> --- /dev/null > >> +++ b/arch/arm/cpu/u-boot.lds > >> @@ -0,0 +1,91 @@ > >> +/* > >> + * Copyright (c) 2004-2008 Texas Instruments > >> + * > >> + * (C) Copyright 2002 > >> + * Gary Jennejohn, DENX Software Engineering,<garyj@denx.de> > >> + * > >> + * See file CREDITS for list of people who contributed to this > >> + * project. > >> + * > >> + * This program is free software; you can redistribute it and/or > >> + * modify it under the terms of the GNU General Public License as > >> + * published by the Free Software Foundation; either version 2 of > >> + * the License, or (at your option) any later version. > >> + * > >> + * This program is distributed in the hope that it will be useful, > >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of > >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the > >> + * GNU General Public License for more details. > >> + * > >> + * You should have received a copy of the GNU General Public License > >> + * along with this program; if not, write to the Free Software > >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, > >> + * MA 02111-1307 USA > >> + */ > >> + > >> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") > >> +OUTPUT_ARCH(arm) > >> +ENTRY(_start) > >> +SECTIONS > >> +{ > >> + . = 0x00000000; > >> + > >> + . = ALIGN(4); > >> + .text : > >> + { > >> + __text_start = .; > >> + CPUDIR/start.o (.text) > >> + *(.text) > >> + } > >> + > >> + . = ALIGN(4); > >> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } > >> + > >> + . = ALIGN(4); > >> + .data : { > >> + *(.data) > >> + } > >> + > >> + . = ALIGN(4); > >> + > >> + . = .; > >> + __u_boot_cmd_start = .; > >> + .u_boot_cmd : { *(.u_boot_cmd) } > >> + __u_boot_cmd_end = .; > >> + > >> + . = ALIGN(4); > > > > This "ALIGN(4)" is what upsets my edminiv2 build and makes it not > > binary-identical. It is not in the current arm926ejs liner script. I will > > check if adding it to the current arm926ejs script produces a working and > > binary-identical u-boot. > > OK, but realistically we copy a word at a time (at least) and the > .rel.dyn region is going to be word-aligned I think. All we are doing > here is making sure that the image ends on a word boundary, which > seems reasonable to me. > > In other words, I would like the __image_copy_start and > __image_copy_end symbols to be word-aligned. > > >> + __image_copy_end = .; > >> + > >> + .rel.dyn : { > >> + __rel_dyn_start = .; > >> + *(.rel*) > >> + __rel_dyn_end = .; > >> + } > >> + > >> + .dynsym : { > >> + __dynsym_start = .; > >> + *(.dynsym) > >> + } > >> + > >> + _end = .; > > > > Below is what I assume to be the reservation for MMU. > > > >> + . = ALIGN(4096); > >> + > >> + .mmutable : { > >> + *(.mmutable) > >> + } > > > > ... and I don't like it at all, more so if it is going to be actually 16 > > KB, because it seems to me we're wasting memory and creating a hole in > > the middle of our in-RAM binary, and I'm not sure we need to do it here > > in the first place. Do we need to have that MMU region mapped over DDR? > > And if so, do we need to have it mapped in the middle of u-boot? Plus > > you're placing it after .dynsym and .rel.dyn, but possibly overlaid with > > .bss. Normally this area should have gone by the time we get to use BSS, > > but assumption is the mother of all screw-ups. > > Yes it will be 16KB, although of course only if it exists. At present > it is only used for pxa so including it here allows pxa boards to > build. > > The hole is not in the middle of the binary, but at the end. The BSS > may overlay it if large enough, but that doesn't take affect until > after relocation. > > I'm not thrilled with it either, but it does allow us to have an > option to set up the MMU table at compile time for those that need it. > Having thought about it a bit more I feel that we should be able to > set this up at run-time instead, but still, it is needed at present > for pxa, so... > > I have question also, for Marek. Should this be 16KB aligned, since > ARM needs this I think. The alignment is currently provided by pxa's > start.S but we might as well be explicit here I think. Yes, but I believe it should be only 4k aligned. This part is special in more ways actually. This is only used on PXA250, since that has no SRAM and therefore no place for stack at boottime. But to allow locking cachelines (to create space for stack) we need the MMU table ready. Therefore I created the MMU table with 1:1 mapping in the ROM at compile time and in the init code I point the MMU to this table. That's about it M > > >> + .bss __rel_dyn_start (OVERLAY) : { > >> + __bss_start = .; > >> + *(.bss) > >> + . = ALIGN(4); > >> + __bss_end__ = .; > >> + } > >> + > >> + /DISCARD/ : { *(.dynstr*) } > >> + /DISCARD/ : { *(.dynamic*) } > >> + /DISCARD/ : { *(.plt*) } > >> + /DISCARD/ : { *(.interp*) } > >> + /DISCARD/ : { *(.gnu*) } > >> +} > > > > Amicalement, > > -- > > Albert. > > Regards, > Simon
Hi Marek, On Tue, Feb 21, 2012 at 12:24 PM, Marek Vasut <marek.vasut@gmail.com> wrote: >> Hi Albert, >> >> On Tue, Feb 21, 2012 at 5:11 AM, Albert ARIBAUD >> >> <albert.u.boot@aribaud.net> wrote: >> > Hi Simon, >> > >> > Le 21/02/2012 07:17, Simon Glass a écrit : >> >> Most ARM CPUs use a very similar link script. This adds a basic >> >> script that can be used by most CPUs. >> >> >> >> Two new symbols are introduced which are intended to eventually be >> >> defined on all architectures to make things easier for generic >> >> relocation and reduce special-case code for each architecture: >> >> >> >> __text_start is the start of the text area (equivalent to the existing >> >> _start on ARM). It marks the start of the region which must be copied >> >> to a new location during relocation. >> > >> > Please name it _image_copy_start, not __text_start >> >> OK will do >> >> >> __image_copy_end is the end of the region which must be copied to a new >> >> location during relocation. It is normally equal to the start of the BSS >> >> region, but this can vary in some cases (SPL?). Making this an explicit >> >> symbol on its own removes any ambiguity and permits common code to >> >> always do the right thing. >> >> >> >> This new script makes use of CPUDIR, now defined by both Makefile and >> >> spl/Makefile, to find the directory containing the start.o object file, >> >> which is always placed first in the image. >> >> >> >> To permit MMU setup prior to relocation (as used by pxa) we add an area >> >> to the link script which contains space for this. This is taken >> >> from commit 7f4cfcf. CPUs can put the contents in there using their >> >> start.S file. BTW, shouldn't that area be 16KB-aligned? >> >> >> >> Signed-off-by: Simon Glass<sjg@chromium.org> >> >> --- >> >> Changes in v3: >> >> - Add more comments in the commit message >> >> - Add section for MMU area, as required by pxa >> >> >> >> arch/arm/cpu/u-boot.lds | 91 >> >> +++++++++++++++++++++++++++++++++++++++++++++++ >> >> 1 files changed, 91 insertions(+), 0 deletions(-) >> >> create mode 100644 arch/arm/cpu/u-boot.lds >> >> >> >> diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds >> >> new file mode 100644 >> >> index 0000000..7a859fc >> >> --- /dev/null >> >> +++ b/arch/arm/cpu/u-boot.lds >> >> @@ -0,0 +1,91 @@ >> >> +/* >> >> + * Copyright (c) 2004-2008 Texas Instruments >> >> + * >> >> + * (C) Copyright 2002 >> >> + * Gary Jennejohn, DENX Software Engineering,<garyj@denx.de> >> >> + * >> >> + * See file CREDITS for list of people who contributed to this >> >> + * project. >> >> + * >> >> + * This program is free software; you can redistribute it and/or >> >> + * modify it under the terms of the GNU General Public License as >> >> + * published by the Free Software Foundation; either version 2 of >> >> + * the License, or (at your option) any later version. >> >> + * >> >> + * This program is distributed in the hope that it will be useful, >> >> + * but WITHOUT ANY WARRANTY; without even the implied warranty of >> >> + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the >> >> + * GNU General Public License for more details. >> >> + * >> >> + * You should have received a copy of the GNU General Public License >> >> + * along with this program; if not, write to the Free Software >> >> + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, >> >> + * MA 02111-1307 USA >> >> + */ >> >> + >> >> +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") >> >> +OUTPUT_ARCH(arm) >> >> +ENTRY(_start) >> >> +SECTIONS >> >> +{ >> >> + . = 0x00000000; >> >> + >> >> + . = ALIGN(4); >> >> + .text : >> >> + { >> >> + __text_start = .; >> >> + CPUDIR/start.o (.text) >> >> + *(.text) >> >> + } >> >> + >> >> + . = ALIGN(4); >> >> + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } >> >> + >> >> + . = ALIGN(4); >> >> + .data : { >> >> + *(.data) >> >> + } >> >> + >> >> + . = ALIGN(4); >> >> + >> >> + . = .; >> >> + __u_boot_cmd_start = .; >> >> + .u_boot_cmd : { *(.u_boot_cmd) } >> >> + __u_boot_cmd_end = .; >> >> + >> >> + . = ALIGN(4); >> > >> > This "ALIGN(4)" is what upsets my edminiv2 build and makes it not >> > binary-identical. It is not in the current arm926ejs liner script. I will >> > check if adding it to the current arm926ejs script produces a working and >> > binary-identical u-boot. >> >> OK, but realistically we copy a word at a time (at least) and the >> .rel.dyn region is going to be word-aligned I think. All we are doing >> here is making sure that the image ends on a word boundary, which >> seems reasonable to me. >> >> In other words, I would like the __image_copy_start and >> __image_copy_end symbols to be word-aligned. >> >> >> + __image_copy_end = .; >> >> + >> >> + .rel.dyn : { >> >> + __rel_dyn_start = .; >> >> + *(.rel*) >> >> + __rel_dyn_end = .; >> >> + } >> >> + >> >> + .dynsym : { >> >> + __dynsym_start = .; >> >> + *(.dynsym) >> >> + } >> >> + >> >> + _end = .; >> > >> > Below is what I assume to be the reservation for MMU. >> > >> >> + . = ALIGN(4096); >> >> + >> >> + .mmutable : { >> >> + *(.mmutable) >> >> + } >> > >> > ... and I don't like it at all, more so if it is going to be actually 16 >> > KB, because it seems to me we're wasting memory and creating a hole in >> > the middle of our in-RAM binary, and I'm not sure we need to do it here >> > in the first place. Do we need to have that MMU region mapped over DDR? >> > And if so, do we need to have it mapped in the middle of u-boot? Plus >> > you're placing it after .dynsym and .rel.dyn, but possibly overlaid with >> > .bss. Normally this area should have gone by the time we get to use BSS, >> > but assumption is the mother of all screw-ups. >> >> Yes it will be 16KB, although of course only if it exists. At present >> it is only used for pxa so including it here allows pxa boards to >> build. >> >> The hole is not in the middle of the binary, but at the end. The BSS >> may overlay it if large enough, but that doesn't take affect until >> after relocation. >> >> I'm not thrilled with it either, but it does allow us to have an >> option to set up the MMU table at compile time for those that need it. >> Having thought about it a bit more I feel that we should be able to >> set this up at run-time instead, but still, it is needed at present >> for pxa, so... >> >> I have question also, for Marek. Should this be 16KB aligned, since >> ARM needs this I think. The alignment is currently provided by pxa's >> start.S but we might as well be explicit here I think. > > Yes, but I believe it should be only 4k aligned. This part is special in more > ways actually. > > This is only used on PXA250, since that has no SRAM and therefore no place for > stack at boottime. But to allow locking cachelines (to create space for stack) > we need the MMU table ready. Therefore I created the MMU table with 1:1 mapping > in the ROM at compile time and in the init code I point the MMU to this table. > > That's about it OK thank you. Since this isn't needed for other CPUs and given Albert's concerns I will mark this section as deprecated in my v4 patch, just to make sure others don't start using it. > > M Regards, Simon > >> >> >> + .bss __rel_dyn_start (OVERLAY) : { >> >> + __bss_start = .; >> >> + *(.bss) >> >> + . = ALIGN(4); >> >> + __bss_end__ = .; >> >> + } >> >> + >> >> + /DISCARD/ : { *(.dynstr*) } >> >> + /DISCARD/ : { *(.dynamic*) } >> >> + /DISCARD/ : { *(.plt*) } >> >> + /DISCARD/ : { *(.interp*) } >> >> + /DISCARD/ : { *(.gnu*) } >> >> +} >> > >> > Amicalement, >> > -- >> > Albert. >> >> Regards, >> Simon
Hi Albert, On Tue, Feb 28, 2012 at 1:25 PM, Albert ARIBAUD <albert.u.boot@aribaud.net> wrote: > Hi Simon, > > Le 21/02/2012 21:14, Simon Glass a écrit : >> >> Hi Albert, >> >> >> On Tue, Feb 21, 2012 at 11:52 AM, Albert ARIBAUD >> <albert.u.boot@aribaud.net> wrote: >>> >>> Hi Simon, >>> >>> Le 21/02/2012 18:02, Simon Glass a écrit : >>> >>> >>>>>> + . = ALIGN(4); >>>>> >>>>> >>>>> >>>>> >>>>> This "ALIGN(4)" is what upsets my edminiv2 build and makes it not >>>>> binary-identical. It is not in the current arm926ejs liner script. I >>>>> will >>>>> check if adding it to the current arm926ejs script produces a working >>>>> and >>>>> binary-identical u-boot. >>>> >>>> >>>> >>>> OK, but realistically we copy a word at a time (at least) and the >>>> .rel.dyn region is going to be word-aligned I think. All we are doing >>>> here is making sure that the image ends on a word boundary, which >>>> seems reasonable to me. >>>> >>>> In other words, I would like the __image_copy_start and >>>> __image_copy_end symbols to be word-aligned. >>> >>> >>> >>> I understand the requirement and agree to it -- only, it seems to me it >>> is >>> already fulfilled in the current lds files, so I still fail to see what >>> breaks 'near binary identity'. >> >> >> If we add any symbols or change the value of any of them, then the >> binary file may change. You can see the differences by doing something >> like: > > > This statement is true in a very general fashion, but becomes false for many > cases, including the one where the symbol is added at link stage and not > referenced in the build, which is the case for edminiv2. Then the ELF file's > symbol sections may change, but the .text and .data sections have no reason > to. I agree with that. But do you see this behaviour? I did initially, until I realized that it was just that '-dirty' was be appended to the version string, which was increasing the .rodata size and just changing all the offsets in the text section. Once I committed the change and rebuilt, the problem went away. Please can you confirm what differences you are seeing with things like: armv7a-cros-linux-gnueabi-objdump -h u-boot armv7a-cros-linux-gnueabi-objdump -t u-boot armv7a-cros-linux-gnueabi-objdump -d u-boot ... > > Plus, you did not address my note that the current .lds already aligns the > start and end of copy section to a multiple of 4. I think I missed that comment. I saw that you said that the ALIGN before __image_copy_end was not in the arm926-ejs link script, but when I looked I did in fact see it, e.g. in e37ae40: arch/arm/cpu/arm926ejs/u-boot.lds: ... . = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = ALIGN(4); ^^^^^^^^^^^^^ .rel.dyn : { ... In the link script in this patch I have: . = ALIGN(4); . = .; __u_boot_cmd_start = .; .u_boot_cmd : { *(.u_boot_cmd) } __u_boot_cmd_end = .; . = ALIGN(4); __image_copy_end = .; .rel.dyn : { __rel_dyn_start = .; Granted, the last ALIGN should not be needed since the size of commands should be word-aligned anyway, and the first command is clearly word-aligned, but it does make things clear I think. Can you please explain more what you mean by ' the current .lds already aligns the start and end of copy section to a multiple of 4'. And also, how you would like me to change this patch. Just remove the last ALIGN? > > >> armv7a-cros-linux-gnueabi-objdump -b binary -m arm -D u-boot.bin >> >> on each file (but I guess you know that). > > > Yes, plus 'od -t x1z -A x u-boot.bin > u-boot.lst' :) and it does not > explain why the .text and .data sections should undergo any change when the > .lds introduces a symbol that neither section references. See my note above about 'dirty', but if you are saying it is due to the ALIGN, I am not sure what to say. I don't see that, so perhaps it is best to email the commands you are using so I can replicate. Regards, Smion > > >> Regards, >> Simon > > > Amicalement, > -- > Albert.
diff --git a/arch/arm/cpu/u-boot.lds b/arch/arm/cpu/u-boot.lds new file mode 100644 index 0000000..7a859fc --- /dev/null +++ b/arch/arm/cpu/u-boot.lds @@ -0,0 +1,91 @@ +/* + * Copyright (c) 2004-2008 Texas Instruments + * + * (C) Copyright 2002 + * Gary Jennejohn, DENX Software Engineering, <garyj@denx.de> + * + * See file CREDITS for list of people who contributed to this + * project. + * + * This program is free software; you can redistribute it and/or + * modify it under the terms of the GNU General Public License as + * published by the Free Software Foundation; either version 2 of + * the License, or (at your option) any later version. + * + * This program is distributed in the hope that it will be useful, + * but WITHOUT ANY WARRANTY; without even the implied warranty of + * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + * GNU General Public License for more details. + * + * You should have received a copy of the GNU General Public License + * along with this program; if not, write to the Free Software + * Foundation, Inc., 59 Temple Place, Suite 330, Boston, + * MA 02111-1307 USA + */ + +OUTPUT_FORMAT("elf32-littlearm", "elf32-littlearm", "elf32-littlearm") +OUTPUT_ARCH(arm) +ENTRY(_start) +SECTIONS +{ + . = 0x00000000; + + . = ALIGN(4); + .text : + { + __text_start = .; + CPUDIR/start.o (.text) + *(.text) + } + + . = ALIGN(4); + .rodata : { *(SORT_BY_ALIGNMENT(SORT_BY_NAME(.rodata*))) } + + . = ALIGN(4); + .data : { + *(.data) + } + + . = ALIGN(4); + + . = .; + __u_boot_cmd_start = .; + .u_boot_cmd : { *(.u_boot_cmd) } + __u_boot_cmd_end = .; + + . = ALIGN(4); + + __image_copy_end = .; + + .rel.dyn : { + __rel_dyn_start = .; + *(.rel*) + __rel_dyn_end = .; + } + + .dynsym : { + __dynsym_start = .; + *(.dynsym) + } + + _end = .; + + . = ALIGN(4096); + + .mmutable : { + *(.mmutable) + } + + .bss __rel_dyn_start (OVERLAY) : { + __bss_start = .; + *(.bss) + . = ALIGN(4); + __bss_end__ = .; + } + + /DISCARD/ : { *(.dynstr*) } + /DISCARD/ : { *(.dynamic*) } + /DISCARD/ : { *(.plt*) } + /DISCARD/ : { *(.interp*) } + /DISCARD/ : { *(.gnu*) } +}
Most ARM CPUs use a very similar link script. This adds a basic script that can be used by most CPUs. Two new symbols are introduced which are intended to eventually be defined on all architectures to make things easier for generic relocation and reduce special-case code for each architecture: __text_start is the start of the text area (equivalent to the existing _start on ARM). It marks the start of the region which must be copied to a new location during relocation. __image_copy_end is the end of the region which must be copied to a new location during relocation. It is normally equal to the start of the BSS region, but this can vary in some cases (SPL?). Making this an explicit symbol on its own removes any ambiguity and permits common code to always do the right thing. This new script makes use of CPUDIR, now defined by both Makefile and spl/Makefile, to find the directory containing the start.o object file, which is always placed first in the image. To permit MMU setup prior to relocation (as used by pxa) we add an area to the link script which contains space for this. This is taken from commit 7f4cfcf. CPUs can put the contents in there using their start.S file. BTW, shouldn't that area be 16KB-aligned? Signed-off-by: Simon Glass <sjg@chromium.org> --- Changes in v3: - Add more comments in the commit message - Add section for MMU area, as required by pxa arch/arm/cpu/u-boot.lds | 91 +++++++++++++++++++++++++++++++++++++++++++++++ 1 files changed, 91 insertions(+), 0 deletions(-) create mode 100644 arch/arm/cpu/u-boot.lds