[PATCH] blackfin: Cleanup linker script using new linker script macros.

[PATCH] blackfin: Cleanup linker script using new linker script macros.

[Tim Abbott]

Signed-off-by: Tim Abbott <tabbott@ksplice.com>
Cc: Bryan Wu <cooloney@kernel.org>
Cc: uclinux-dist-devel@blackfin.uclinux.org
Cc: Sam Ravnborg <sam@ravnborg.org>
---
 arch/blackfin/kernel/vmlinux.lds.S |   54 +++--------------------------------
 1 files changed, 5 insertions(+), 49 deletions(-)

diff --git a/arch/blackfin/kernel/vmlinux.lds.S b/arch/blackfin/kernel/vmlinux.lds.S
index 6ac307c..91f5057 100644
--- a/arch/blackfin/kernel/vmlinux.lds.S
+++ b/arch/blackfin/kernel/vmlinux.lds.S
@@ -96,8 +96,7 @@ SECTIONS
 	{
 		__sdata = .;
 		/* This gets done first, so the glob doesn't suck it in */
-		. = ALIGN(32);
-		*(.data.cacheline_aligned)
+		CACHELINE_ALIGNED_DATA(32)
 
 #if !L1_DATA_A_LENGTH
 		. = ALIGN(32);
@@ -116,12 +115,7 @@ SECTIONS
 		DATA_DATA
 		CONSTRUCTORS
 
-		/* make sure the init_task is aligned to the
-		 * kernel thread size so we can locate the kernel
-		 * stack properly and quickly.
-		 */
-		. = ALIGN(THREAD_SIZE);
-		*(.init_task.data)
+		INIT_TASK_DATA(THREAD_SIZE)
 
 		__edata = .;
 	}
@@ -134,39 +128,10 @@ SECTIONS
 	. = ALIGN(PAGE_SIZE);
 	___init_begin = .;
 
-	.init.text :
-	{
-		. = ALIGN(PAGE_SIZE);
-		__sinittext = .;
-		INIT_TEXT
-		__einittext = .;
-	}
-	.init.data :
-	{
-		. = ALIGN(16);
-		INIT_DATA
-	}
-	.init.setup :
-	{
-		. = ALIGN(16);
-		___setup_start = .;
-		*(.init.setup)
-		___setup_end = .;
-	}
-	.initcall.init :
-	{
-		___initcall_start = .;
-		INITCALLS
-		___initcall_end = .;
-	}
-	.con_initcall.init :
-	{
-		___con_initcall_start = .;
-		*(.con_initcall.init)
-		___con_initcall_end = .;
-	}
+	INIT_TEXT_SECTION(PAGE_SIZE)
+	. = ALIGN(16);
+	INIT_DATA_SECTION(16)
 	PERCPU(4)
-	SECURITY_INIT
 
 	/* we have to discard exit text and such at runtime, not link time, to
 	 * handle embedded cross-section references (alt instructions, bug
@@ -181,15 +146,6 @@ SECTIONS
 		EXIT_DATA
 	}
 
-	.init.ramfs :
-	{
-		. = ALIGN(4);
-		___initramfs_start = .;
-		*(.init.ramfs)
-		. = ALIGN(4);
-		___initramfs_end = .;
-	}
-
 	__l1_lma_start = .;
 
 	.text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))
-- 
1.6.3.3

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Mike Frysinger]

the larger padding in the initramfs is kind of annoying as i cant see
any need to pad it to PAGE_SIZE.  since the initramfs is released with
the rest of the init section, it doesnt need whole pages.  a quick
test shows that it does waste a few kb in reality.  default build for
BF533-STAMP for example shows 0x1000 difference.

in terms of correctness, this change misses a reference to the now
deleted .init.ramfs:
-       .init.ramfs :
-       {
-       .....
-       }
-
       .text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))

so that .text_l1 needs to updated to refer to the new section before
it (.exit.data in this case).  once i make that change, the resulting
link looks the same (minus the initramfs thing mentioned earlier), and
it does boot.
-mike

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Tim Abbott]

On Tue, 15 Sep 2009, Mike Frysinger wrote:

> the larger padding in the initramfs is kind of annoying as i cant see
> any need to pad it to PAGE_SIZE.  since the initramfs is released with
> the rest of the init section, it doesnt need whole pages.  a quick
> test shows that it does waste a few kb in reality.  default build for
> BF533-STAMP for example shows 0x1000 difference.
> 
> in terms of correctness, this change misses a reference to the now
> deleted .init.ramfs:
> -       .init.ramfs :
> -       {
> -       .....
> -       }
> -
>        .text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))
> 
> so that .text_l1 needs to updated to refer to the new section before
> it (.exit.data in this case).  once i make that change, the resulting
> link looks the same (minus the initramfs thing mentioned earlier), and
> it does boot.

OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add 
another argument specifying an alignment level for .init.ramfs.  It'd be 
inconvenient to add that right now since there are a lot of patches in 
linux-next or otherwise in flight that introduce uses of 
INIT_DATA_SECTION, and those patches would all be broken by changing this 
now.  Once the dust settles on that for this release, I'll submit a patch 
adding said argument to INIT_DATA_SECTION.

	-Tim Abbott

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Mike Frysinger]

On Wed, Sep 16, 2009 at 11:58, Tim Abbott wrote:
> On Tue, 15 Sep 2009, Mike Frysinger wrote:
>> the larger padding in the initramfs is kind of annoying as i cant see
>> any need to pad it to PAGE_SIZE.  since the initramfs is released with
>> the rest of the init section, it doesnt need whole pages.  a quick
>> test shows that it does waste a few kb in reality.  default build for
>> BF533-STAMP for example shows 0x1000 difference.
>
> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
> another argument specifying an alignment level for .init.ramfs.  It'd be
> inconvenient to add that right now since there are a lot of patches in
> linux-next or otherwise in flight that introduce uses of
> INIT_DATA_SECTION, and those patches would all be broken by changing this
> now.  Once the dust settles on that for this release, I'll submit a patch
> adding said argument to INIT_DATA_SECTION.

sounds good to me.  too bad the function alignment isnt specified in
arch linkage.h, otherwise i'd suggest we default to that rather than
PAGE_SIZE.  as seen in the current Blackfin linker script, we only
need the normal .text alignment of 4 bytes.
-mike

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Sam Ravnborg]

On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
> On Tue, 15 Sep 2009, Mike Frysinger wrote:
> 
> > the larger padding in the initramfs is kind of annoying as i cant see
> > any need to pad it to PAGE_SIZE.  since the initramfs is released with
> > the rest of the init section, it doesnt need whole pages.  a quick
> > test shows that it does waste a few kb in reality.  default build for
> > BF533-STAMP for example shows 0x1000 difference.
> > 
> > in terms of correctness, this change misses a reference to the now
> > deleted .init.ramfs:
> > -       .init.ramfs :
> > -       {
> > -       .....
> > -       }
> > -
> >        .text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))
> > 
> > so that .text_l1 needs to updated to refer to the new section before
> > it (.exit.data in this case).  once i make that change, the resulting
> > link looks the same (minus the initramfs thing mentioned earlier), and
> > it does boot.
> 
> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add 
> another argument specifying an alignment level for .init.ramfs.  It'd be 
> inconvenient to add that right now since there are a lot of patches in 
> linux-next or otherwise in flight that introduce uses of 
> INIT_DATA_SECTION, and those patches would all be broken by changing this 
> now.  Once the dust settles on that for this release, I'll submit a patch 
> adding said argument to INIT_DATA_SECTION.

But this is all discarded during runtime so the added alignment has no cost in the end - no?

	Sam

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Mike Frysinger]

On Wed, Sep 16, 2009 at 16:26, Sam Ravnborg wrote:
> On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
>> On Tue, 15 Sep 2009, Mike Frysinger wrote:
>> > the larger padding in the initramfs is kind of annoying as i cant see
>> > any need to pad it to PAGE_SIZE.  since the initramfs is released with
>> > the rest of the init section, it doesnt need whole pages.  a quick
>> > test shows that it does waste a few kb in reality.  default build for
>> > BF533-STAMP for example shows 0x1000 difference.
>> >
>> > in terms of correctness, this change misses a reference to the now
>> > deleted .init.ramfs:
>> > -       .init.ramfs :
>> > -       {
>> > -       .....
>> > -       }
>> > -
>> >        .text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))
>> >
>> > so that .text_l1 needs to updated to refer to the new section before
>> > it (.exit.data in this case).  once i make that change, the resulting
>> > link looks the same (minus the initramfs thing mentioned earlier), and
>> > it does boot.
>>
>> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
>> another argument specifying an alignment level for .init.ramfs.  It'd be
>> inconvenient to add that right now since there are a lot of patches in
>> linux-next or otherwise in flight that introduce uses of
>> INIT_DATA_SECTION, and those patches would all be broken by changing this
>> now.  Once the dust settles on that for this release, I'll submit a patch
>> adding said argument to INIT_DATA_SECTION.
>
> But this is all discarded during runtime so the added alignment has no cost in the end - no?

once things are booted, there should be no difference.  but
storage/boot costs increase (you have to store/extract/copy that extra
data).  you know how miserly we embedded people like to be ;).
-mike

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Tim Abbott]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1218 bytes --]

On Wed, 16 Sep 2009, Mike Frysinger wrote:

> On Wed, Sep 16, 2009 at 16:26, Sam Ravnborg wrote:
> > On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
> >> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
> >> another argument specifying an alignment level for .init.ramfs.  It'd be
> >> inconvenient to add that right now since there are a lot of patches in
> >> linux-next or otherwise in flight that introduce uses of
> >> INIT_DATA_SECTION, and those patches would all be broken by changing this
> >> now.  Once the dust settles on that for this release, I'll submit a patch
> >> adding said argument to INIT_DATA_SECTION.
> >
> > But this is all discarded during runtime so the added alignment has no cost in the end - no?
> 
> once things are booted, there should be no difference.  but
> storage/boot costs increase (you have to store/extract/copy that extra
> data).  you know how miserly we embedded people like to be ;).

OK, so how do you want to do this?  The options I see are:
(1) we merge this patch now, and add the new alignment argument for -rc2
(2) we add the alignment argument sometime after -rc1 and then merge this 
for -rc2

	-Tim Abbott

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Mike Frysinger]

On Tue, Sep 22, 2009 at 11:29, Tim Abbott wrote:
> On Wed, 16 Sep 2009, Mike Frysinger wrote:
>> On Wed, Sep 16, 2009 at 16:26, Sam Ravnborg wrote:
>> > On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
>> >> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
>> >> another argument specifying an alignment level for .init.ramfs.  It'd be
>> >> inconvenient to add that right now since there are a lot of patches in
>> >> linux-next or otherwise in flight that introduce uses of
>> >> INIT_DATA_SECTION, and those patches would all be broken by changing this
>> >> now.  Once the dust settles on that for this release, I'll submit a patch
>> >> adding said argument to INIT_DATA_SECTION.
>> >
>> > But this is all discarded during runtime so the added alignment has no cost in the end - no?
>>
>> once things are booted, there should be no difference.  but
>> storage/boot costs increase (you have to store/extract/copy that extra
>> data).  you know how miserly we embedded people like to be ;).
>
> OK, so how do you want to do this?  The options I see are:
> (1) we merge this patch now, and add the new alignment argument for -rc2
> (2) we add the alignment argument sometime after -rc1 and then merge this
> for -rc2

doing it in two steps is OK by me and sounds like it'd be easier for you
-mike

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Tim Abbott]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1683 bytes --]

On Tue, 22 Sep 2009, Mike Frysinger wrote:

> On Tue, Sep 22, 2009 at 11:29, Tim Abbott wrote:
> > On Wed, 16 Sep 2009, Mike Frysinger wrote:
> >> On Wed, Sep 16, 2009 at 16:26, Sam Ravnborg wrote:
> >> > On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
> >> >> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
> >> >> another argument specifying an alignment level for .init.ramfs.  It'd be
> >> >> inconvenient to add that right now since there are a lot of patches in
> >> >> linux-next or otherwise in flight that introduce uses of
> >> >> INIT_DATA_SECTION, and those patches would all be broken by changing this
> >> >> now.  Once the dust settles on that for this release, I'll submit a patch
> >> >> adding said argument to INIT_DATA_SECTION.
> >> >
> >> > But this is all discarded during runtime so the added alignment has no cost in the end - no?
> >>
> >> once things are booted, there should be no difference.  but
> >> storage/boot costs increase (you have to store/extract/copy that extra
> >> data).  you know how miserly we embedded people like to be ;).
> >
> > OK, so how do you want to do this?  The options I see are:
> > (1) we merge this patch now, and add the new alignment argument for -rc2
> > (2) we add the alignment argument sometime after -rc1 and then merge this
> > for -rc2
> 
> doing it in two steps is OK by me and sounds like it'd be easier for you

Both options involve two steps -- but as (1) is obviously easier for me, I 
assume that's what you were referring to.  Thanks.

So are you going to send this to Linus?  I'd be happy to do so, but I'd 
need your ack.

	-Tim Abbott

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Mike Frysinger]

On Tue, Sep 22, 2009 at 11:39, Tim Abbott wrote:
> On Tue, 22 Sep 2009, Mike Frysinger wrote:
>> On Tue, Sep 22, 2009 at 11:29, Tim Abbott wrote:
>> > On Wed, 16 Sep 2009, Mike Frysinger wrote:
>> >> On Wed, Sep 16, 2009 at 16:26, Sam Ravnborg wrote:
>> >> > On Wed, Sep 16, 2009 at 11:58:01AM -0400, Tim Abbott wrote:
>> >> >> OK.  I guess we should plan to modify the INIT_DATA_SECTION macro to add
>> >> >> another argument specifying an alignment level for .init.ramfs.  It'd be
>> >> >> inconvenient to add that right now since there are a lot of patches in
>> >> >> linux-next or otherwise in flight that introduce uses of
>> >> >> INIT_DATA_SECTION, and those patches would all be broken by changing this
>> >> >> now.  Once the dust settles on that for this release, I'll submit a patch
>> >> >> adding said argument to INIT_DATA_SECTION.
>> >> >
>> >> > But this is all discarded during runtime so the added alignment has no cost in the end - no?
>> >>
>> >> once things are booted, there should be no difference.  but
>> >> storage/boot costs increase (you have to store/extract/copy that extra
>> >> data).  you know how miserly we embedded people like to be ;).
>> >
>> > OK, so how do you want to do this?  The options I see are:
>> > (1) we merge this patch now, and add the new alignment argument for -rc2
>> > (2) we add the alignment argument sometime after -rc1 and then merge this
>> > for -rc2
>>
>> doing it in two steps is OK by me and sounds like it'd be easier for you
>
> Both options involve two steps -- but as (1) is obviously easier for me, I
> assume that's what you were referring to.  Thanks.
>
> So are you going to send this to Linus?  I'd be happy to do so, but I'd
> need your ack.

if you apply the .text_l1 update (.init.ramfs -> .exit.data), then you
can add my s-o-b.  otherwise the original patch as posted is broken.
-mike

Re: [PATCH] blackfin: Cleanup linker script using new linker script macros.

[Tim Abbott]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 597 bytes --]

On Tue, 22 Sep 2009, Mike Frysinger wrote:

> On Tue, Sep 22, 2009 at 11:39, Tim Abbott wrote:
> > So are you going to send this to Linus?  I'd be happy to do so, but I'd
> > need your ack.
> 
> if you apply the .text_l1 update (.init.ramfs -> .exit.data), then you
> can add my s-o-b.  otherwise the original patch as posted is broken.

Right, I modified the patch in my git tree when you first mentioned it 
like so:

-	.text_l1 L1_CODE_START : AT(LOADADDR(.init.ramfs) + SIZEOF(.init.ramfs))
+	.text_l1 L1_CODE_START : AT(LOADADDR(.exit.data) + SIZEOF(.exit.data))

	-Tim Abbott