All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
@ 2009-06-13  1:01 Mike Frysinger
  2009-06-13 12:23 ` [uClinux-dev] " David Howells
                   ` (5 more replies)
  0 siblings, 6 replies; 21+ messages in thread
From: Mike Frysinger @ 2009-06-13  1:01 UTC (permalink / raw)
  To: uclinux-dev
  Cc: linux-kernel, uclinux-dist-devel, David McCullough, Greg Ungerer,
	Paul Mundt, Jie Zhang, Bernd Schmidt

From: Jie Zhang <jie.zhang@analog.com>

The Blackfin port has custom program header flags/addresses for
automatically loading regions into the dedicated on-chip SRAM.  So add a
hook for ports to leverage.

Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Bernd Schmidt <bernds_cb1@t-online.de>
---
 arch/blackfin/include/asm/elf.h         |    8 +++
 arch/blackfin/kernel/Makefile           |    1 +
 arch/blackfin/kernel/binfmt_elf_fdpic.c |   80 +++++++++++++++++++++++++++++++
 fs/binfmt_elf_fdpic.c                   |    7 +++
 4 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 arch/blackfin/kernel/binfmt_elf_fdpic.c

diff --git a/arch/blackfin/include/asm/elf.h b/arch/blackfin/include/asm/elf.h
index 230e160..aba2506 100644
--- a/arch/blackfin/include/asm/elf.h
+++ b/arch/blackfin/include/asm/elf.h
@@ -124,4 +124,12 @@ do {											\
 
 #define SET_PERSONALITY(ex) set_personality(PER_LINUX)
 
+struct mm_struct;
+struct elf_fdpic_params;
+struct elf32_phdr;
+extern int elf_fdpic_plat_process_phdr(struct mm_struct *, struct elf_fdpic_params *,
+                                       struct elf32_phdr *, unsigned long *, unsigned long *);
+#define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) \
+	elf_fdpic_plat_process_phdr(mm, params, phdr, maddr, disp)
+
 #endif
diff --git a/arch/blackfin/kernel/Makefile b/arch/blackfin/kernel/Makefile
index fd4d432..71c2291 100644
--- a/arch/blackfin/kernel/Makefile
+++ b/arch/blackfin/kernel/Makefile
@@ -15,6 +15,7 @@ else
     obj-y += time.o
 endif
 
+obj-$(CONFIG_BINFMT_ELF_FDPIC)       += binfmt_elf_fdpic.o
 obj-$(CONFIG_IPIPE)                  += ipipe.o
 obj-$(CONFIG_IPIPE_TRACE_MCOUNT)     += mcount.o
 obj-$(CONFIG_BFIN_GPTIMERS)          += gptimers.o
diff --git a/arch/blackfin/kernel/binfmt_elf_fdpic.c b/arch/blackfin/kernel/binfmt_elf_fdpic.c
new file mode 100644
index 0000000..d8192cf
--- /dev/null
+++ b/arch/blackfin/kernel/binfmt_elf_fdpic.c
@@ -0,0 +1,80 @@
+/*
+ * FDPIC ELF hooks
+ *
+ * Copyright (c) 2006-2009 Analog Devices Inc.
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/mm.h>
+#include <linux/elf.h>
+#include <linux/elf-fdpic.h>
+#include <linux/kernel.h>
+
+#include <asm/cacheflush.h>
+#include <asm/dma.h>
+
+int elf_fdpic_plat_process_phdr(struct mm_struct *mm,
+                                struct elf_fdpic_params *params,
+                                struct elf32_phdr *phdr,
+                                unsigned long *maddr, unsigned long *disp)
+{
+	/* 0xfeb00000, 0xfec00000, 0xff700000, 0xff800000, 0xff900000
+	 * and 0xffa00000 are also used in Dynamic linker and GNU ld.
+	 * They need to be kept synchronized.
+	 */
+	unsigned long flag = 0;
+	const char *type = NULL;
+
+	unsigned int e_flags = params->hdr.e_flags;
+	unsigned long p_vaddr = phdr->p_vaddr;
+	unsigned long p_flags = phdr->p_flags;
+
+	if (((e_flags & EF_BFIN_CODE_IN_L1) || p_vaddr == 0xffa00000) &&
+	    (p_flags & (PF_W | PF_X)) == PF_X)
+	{
+		flag = L1_INST_SRAM;
+		type = "L1 instruction";
+
+	} else if (((e_flags & EF_BFIN_DATA_IN_L1) ||
+	            p_vaddr == 0xff700000 ||
+	            p_vaddr == 0xff800000 ||
+	            p_vaddr == 0xff900000) &&
+	           (p_flags & (PF_X | PF_W)) == PF_W)
+	{
+		if (p_vaddr == 0xff800000) {
+			flag = L1_DATA_A_SRAM;
+			type = "L1 Data A";
+		} else if (p_vaddr == 0xff900000) {
+			flag = L1_DATA_B_SRAM;
+			type = "L1 Data B";
+		} else {
+			flag = L1_DATA_SRAM;
+			type = "L1 Data";
+		}
+
+	} else if (p_vaddr == 0xfeb00000 || p_vaddr == 0xfec00000) {
+		flag = L2_SRAM;
+		type = "L2";
+	}
+
+	if (flag) {
+		void *sram_addr = sram_alloc_with_lsl(phdr->p_memsz, flag);
+		if (sram_addr == NULL) {
+			printk(KERN_ERR "elf_fdpic: not enough %s sram\n", type);
+			return -ENOMEM;
+		}
+
+		if (flag & L1_INST_SRAM)
+			safe_dma_memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
+		else
+			memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
+
+		down_write(&mm->mmap_sem);
+		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
+		up_write(&mm->mmap_sem);
+		*maddr = (unsigned long)sram_addr;
+		*disp = 0;
+	}
+
+	return 0;
+}
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index fdb66fa..1bad16c 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1105,6 +1105,13 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
 		    ELF_FDPIC_FLAG_CONTIGUOUS)
 			load_addr += PAGE_ALIGN(phdr->p_memsz + disp);
 
+#ifndef ELF_FDPIC_PLAT_PROCESS_PHDR
+# define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) 0
+#endif
+		ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr, &disp);
+		if (ret)
+			return ret;
+
 		seg->addr = maddr + disp;
 		seg->p_vaddr = phdr->p_vaddr;
 		seg->p_memsz = phdr->p_memsz;
-- 
1.6.3.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
@ 2009-06-13 12:23 ` David Howells
  2009-06-13 16:13 ` Jamie Lokier
                   ` (4 subsequent siblings)
  5 siblings, 0 replies; 21+ messages in thread
From: David Howells @ 2009-06-13 12:23 UTC (permalink / raw)
  To: uClinux development list
  Cc: dhowells, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

Mike Frysinger <vapier@gentoo.org> wrote:

> From: Jie Zhang <jie.zhang@analog.com>
> 
> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.
> 
> Signed-off-by: Jie Zhang <jie.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Bernd Schmidt <bernds_cb1@t-online.de>

Acked-by: David Howells <dhowells@redhat.com>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
  2009-06-13 12:23 ` [uClinux-dev] " David Howells
@ 2009-06-13 16:13 ` Jamie Lokier
  2009-06-13 16:40   ` Mike Frysinger
  2009-06-14  9:43 ` Paul Mundt
                   ` (3 subsequent siblings)
  5 siblings, 1 reply; 21+ messages in thread
From: Jamie Lokier @ 2009-06-13 16:13 UTC (permalink / raw)
  To: uClinux development list
  Cc: linux-kernel, Jie Zhang, Greg Ungerer, uclinux-dist-devel,
	David McCullough

Mike Frysinger wrote:
> From: Jie Zhang <jie.zhang@analog.com>
> 
> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.

What does this have to do with FDPIC?  I don't see anything that is
specific to FDPIC about this code, other than FDPIC being the type of
ELF used on Blackfin.  If an MMU were added to some future Blackfins,
wouldn't this code be used for non-FDPIC ELF too?

It looks like a way for certain special executables to load themselves
into fixed regions of the on-chip SRAM - and promptly crash if another
executable does the same.  Not so much a general executable format, as
a hack to load something specific which should only be done once at a
time.  What am I missing here?

-- Jamie

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize  program header parsing
  2009-06-13 16:13 ` Jamie Lokier
@ 2009-06-13 16:40   ` Mike Frysinger
  2009-06-13 18:25     ` Jamie Lokier
  0 siblings, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2009-06-13 16:40 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: uClinux development list, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

On Sat, Jun 13, 2009 at 12:13, Jamie Lokier wrote:
> Mike Frysinger wrote:
>> From: Jie Zhang <jie.zhang@analog.com>
>>
>> The Blackfin port has custom program header flags/addresses for
>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>> hook for ports to leverage.
>
> What does this have to do with FDPIC?  I don't see anything that is
> specific to FDPIC about this code, other than FDPIC being the type of
> ELF used on Blackfin.  If an MMU were added to some future Blackfins,
> wouldn't this code be used for non-FDPIC ELF too?

no, because with a MMU, the memory would be virtualized and we could
handle it dynamically

> It looks like a way for certain special executables to load themselves
> into fixed regions of the on-chip SRAM - and promptly crash if another
> executable does the same.  Not so much a general executable format, as
> a hack to load something specific which should only be done once at a
> time.  What am I missing here?

the addresses are keys, not fixed and/or "real" addresses
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13 16:40   ` Mike Frysinger
@ 2009-06-13 18:25     ` Jamie Lokier
  2009-06-13 18:26       ` Jamie Lokier
  2009-06-14  0:32       ` Mike Frysinger
  0 siblings, 2 replies; 21+ messages in thread
From: Jamie Lokier @ 2009-06-13 18:25 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: uClinux development list, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

Mike Frysinger wrote:
> On Sat, Jun 13, 2009 at 12:13, Jamie Lokier wrote:
> > Mike Frysinger wrote:
> >> From: Jie Zhang <jie.zhang@analog.com>
> >>
> >> The Blackfin port has custom program header flags/addresses for
> >> automatically loading regions into the dedicated on-chip SRAM.  So add a
> >> hook for ports to leverage.
> >
> > What does this have to do with FDPIC?  I don't see anything that is
> > specific to FDPIC about this code, other than FDPIC being the type of
> > ELF used on Blackfin.  If an MMU were added to some future Blackfins,
> > wouldn't this code be used for non-FDPIC ELF too?
> 
> no, because with a MMU, the memory would be virtualized and we could
> handle it dynamically

Wouldn't you still want to put some things into local L1 SRAM, using thos, perhaps by
flagging it instead of

> > It looks like a way for certain special executables to load themselves
> > into fixed regions of the on-chip SRAM - and promptly crash if another
> > executable does the same.  Not so much a general executable format, as
> > a hack to load something specific which should only be done once at a
> > time.  What am I missing here?
> 
> the addresses are keys, not fixed and/or "real" addresses

Oh, I see that is indeed quite nice :-)

I see it checks for both flags and special address values.  Are the
special address checks mainly historical, as usually flags/types are
used to designate special memory types in ELF.

Anyway,

Acked-By: Jamie Lokier <jamie@shareable.org>

-- Jamie

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13 18:25     ` Jamie Lokier
@ 2009-06-13 18:26       ` Jamie Lokier
  2009-06-14  0:32       ` Mike Frysinger
  1 sibling, 0 replies; 21+ messages in thread
From: Jamie Lokier @ 2009-06-13 18:26 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: uClinux development list, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

Jamie Lokier wrote:
> Wouldn't you still want to put some things into local L1 SRAM, using thos, perhaps by
> flagging it instead of
...

Aiee, slipped on the keyboard.  Ignore.

-- Jamie

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize  program header parsing
  2009-06-13 18:25     ` Jamie Lokier
  2009-06-13 18:26       ` Jamie Lokier
@ 2009-06-14  0:32       ` Mike Frysinger
  2009-06-14  0:42         ` Jie Zhang
  1 sibling, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2009-06-14  0:32 UTC (permalink / raw)
  To: Jamie Lokier
  Cc: uClinux development list, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

On Sat, Jun 13, 2009 at 14:25, Jamie Lokier wrote:
> Mike Frysinger wrote:
>> On Sat, Jun 13, 2009 at 12:13, Jamie Lokier wrote:
>> > Mike Frysinger wrote:
>> >> From: Jie Zhang <jie.zhang@analog.com>
>> >>
>> >> The Blackfin port has custom program header flags/addresses for
>> >> automatically loading regions into the dedicated on-chip SRAM.  So add a
>> >> hook for ports to leverage.
>> >
>> > It looks like a way for certain special executables to load themselves
>> > into fixed regions of the on-chip SRAM - and promptly crash if another
>> > executable does the same.  Not so much a general executable format, as
>> > a hack to load something specific which should only be done once at a
>> > time.  What am I missing here?
>>
>> the addresses are keys, not fixed and/or "real" addresses
>
> Oh, I see that is indeed quite nice :-)
>
> I see it checks for both flags and special address values.  Are the
> special address checks mainly historical, as usually flags/types are
> used to designate special memory types in ELF.

the EF bits are more for smaller/statically linked applications where
you want to place the entire ELF into SRAM.  the special PHDRs are for
selectively compiled code -- i.e. you've done a little bit of
profiling and testing and know which ones are the hot spots.
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-14  0:32       ` Mike Frysinger
@ 2009-06-14  0:42         ` Jie Zhang
  0 siblings, 0 replies; 21+ messages in thread
From: Jie Zhang @ 2009-06-14  0:42 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: Jamie Lokier, uClinux development list, linux-kernel,
	Greg Ungerer, uclinux-dist-devel, David McCullough

Mike Frysinger wrote:
> On Sat, Jun 13, 2009 at 14:25, Jamie Lokier wrote:
>> Mike Frysinger wrote:
>>> On Sat, Jun 13, 2009 at 12:13, Jamie Lokier wrote:
>>>> Mike Frysinger wrote:
>>>>> From: Jie Zhang <jie.zhang@analog.com>
>>>>>
>>>>> The Blackfin port has custom program header flags/addresses for
>>>>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>>>>> hook for ports to leverage.
>>>> It looks like a way for certain special executables to load themselves
>>>> into fixed regions of the on-chip SRAM - and promptly crash if another
>>>> executable does the same.  Not so much a general executable format, as
>>>> a hack to load something specific which should only be done once at a
>>>> time.  What am I missing here?
>>> the addresses are keys, not fixed and/or "real" addresses
>> Oh, I see that is indeed quite nice :-)
>>
>> I see it checks for both flags and special address values.  Are the
>> special address checks mainly historical, as usually flags/types are
>> used to designate special memory types in ELF.
> 
> the EF bits are more for smaller/statically linked applications where
> you want to place the entire ELF into SRAM.  the special PHDRs are for
> selectively compiled code -- i.e. you've done a little bit of
> profiling and testing and know which ones are the hot spots.

Yes. Those e_flags works for the whole ELF file. And these specific 
addresses work as p_flags. May be in future I can add processor specific 
p_flags.


Jie



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
  2009-06-13 12:23 ` [uClinux-dev] " David Howells
  2009-06-13 16:13 ` Jamie Lokier
@ 2009-06-14  9:43 ` Paul Mundt
  2009-06-15  1:43 ` Greg Ungerer
                   ` (2 subsequent siblings)
  5 siblings, 0 replies; 21+ messages in thread
From: Paul Mundt @ 2009-06-14  9:43 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: uclinux-dev, linux-kernel, uclinux-dist-devel, David McCullough,
	Greg Ungerer, Jie Zhang, Bernd Schmidt

On Fri, Jun 12, 2009 at 09:01:09PM -0400, Mike Frysinger wrote:
> From: Jie Zhang <jie.zhang@analog.com>
> 
> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.
> 
> Signed-off-by: Jie Zhang <jie.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Bernd Schmidt <bernds_cb1@t-online.de>

Acked-by: Paul Mundt <lethal@linux-sh.org>

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
                   ` (2 preceding siblings ...)
  2009-06-14  9:43 ` Paul Mundt
@ 2009-06-15  1:43 ` Greg Ungerer
  2009-06-16  8:24 ` [PATCH] " Mike Frysinger
  2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
  5 siblings, 0 replies; 21+ messages in thread
From: Greg Ungerer @ 2009-06-15  1:43 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: uclinux-dev, linux-kernel, uclinux-dist-devel, David McCullough,
	Paul Mundt, Jie Zhang, Bernd Schmidt


Mike Frysinger wrote:
> From: Jie Zhang <jie.zhang@analog.com>
> 
> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.
> 
> Signed-off-by: Jie Zhang <jie.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Bernd Schmidt <bernds_cb1@t-online.de>

Acked-by: Greg Ungerer <gerg@uclinux.org>


>  arch/blackfin/include/asm/elf.h         |    8 +++
>  arch/blackfin/kernel/Makefile           |    1 +
>  arch/blackfin/kernel/binfmt_elf_fdpic.c |   80 +++++++++++++++++++++++++++++++
>  fs/binfmt_elf_fdpic.c                   |    7 +++
>  4 files changed, 96 insertions(+), 0 deletions(-)
>  create mode 100644 arch/blackfin/kernel/binfmt_elf_fdpic.c
> 
> diff --git a/arch/blackfin/include/asm/elf.h b/arch/blackfin/include/asm/elf.h
> index 230e160..aba2506 100644
> --- a/arch/blackfin/include/asm/elf.h
> +++ b/arch/blackfin/include/asm/elf.h
> @@ -124,4 +124,12 @@ do {											\
>  
>  #define SET_PERSONALITY(ex) set_personality(PER_LINUX)
>  
> +struct mm_struct;
> +struct elf_fdpic_params;
> +struct elf32_phdr;
> +extern int elf_fdpic_plat_process_phdr(struct mm_struct *, struct elf_fdpic_params *,
> +                                       struct elf32_phdr *, unsigned long *, unsigned long *);
> +#define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) \
> +	elf_fdpic_plat_process_phdr(mm, params, phdr, maddr, disp)
> +
>  #endif
> diff --git a/arch/blackfin/kernel/Makefile b/arch/blackfin/kernel/Makefile
> index fd4d432..71c2291 100644
> --- a/arch/blackfin/kernel/Makefile
> +++ b/arch/blackfin/kernel/Makefile
> @@ -15,6 +15,7 @@ else
>      obj-y += time.o
>  endif
>  
> +obj-$(CONFIG_BINFMT_ELF_FDPIC)       += binfmt_elf_fdpic.o
>  obj-$(CONFIG_IPIPE)                  += ipipe.o
>  obj-$(CONFIG_IPIPE_TRACE_MCOUNT)     += mcount.o
>  obj-$(CONFIG_BFIN_GPTIMERS)          += gptimers.o
> diff --git a/arch/blackfin/kernel/binfmt_elf_fdpic.c b/arch/blackfin/kernel/binfmt_elf_fdpic.c
> new file mode 100644
> index 0000000..d8192cf
> --- /dev/null
> +++ b/arch/blackfin/kernel/binfmt_elf_fdpic.c
> @@ -0,0 +1,80 @@
> +/*
> + * FDPIC ELF hooks
> + *
> + * Copyright (c) 2006-2009 Analog Devices Inc.
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/elf.h>
> +#include <linux/elf-fdpic.h>
> +#include <linux/kernel.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/dma.h>
> +
> +int elf_fdpic_plat_process_phdr(struct mm_struct *mm,
> +                                struct elf_fdpic_params *params,
> +                                struct elf32_phdr *phdr,
> +                                unsigned long *maddr, unsigned long *disp)
> +{
> +	/* 0xfeb00000, 0xfec00000, 0xff700000, 0xff800000, 0xff900000
> +	 * and 0xffa00000 are also used in Dynamic linker and GNU ld.
> +	 * They need to be kept synchronized.
> +	 */
> +	unsigned long flag = 0;
> +	const char *type = NULL;
> +
> +	unsigned int e_flags = params->hdr.e_flags;
> +	unsigned long p_vaddr = phdr->p_vaddr;
> +	unsigned long p_flags = phdr->p_flags;
> +
> +	if (((e_flags & EF_BFIN_CODE_IN_L1) || p_vaddr == 0xffa00000) &&
> +	    (p_flags & (PF_W | PF_X)) == PF_X)
> +	{
> +		flag = L1_INST_SRAM;
> +		type = "L1 instruction";
> +
> +	} else if (((e_flags & EF_BFIN_DATA_IN_L1) ||
> +	            p_vaddr == 0xff700000 ||
> +	            p_vaddr == 0xff800000 ||
> +	            p_vaddr == 0xff900000) &&
> +	           (p_flags & (PF_X | PF_W)) == PF_W)
> +	{
> +		if (p_vaddr == 0xff800000) {
> +			flag = L1_DATA_A_SRAM;
> +			type = "L1 Data A";
> +		} else if (p_vaddr == 0xff900000) {
> +			flag = L1_DATA_B_SRAM;
> +			type = "L1 Data B";
> +		} else {
> +			flag = L1_DATA_SRAM;
> +			type = "L1 Data";
> +		}
> +
> +	} else if (p_vaddr == 0xfeb00000 || p_vaddr == 0xfec00000) {
> +		flag = L2_SRAM;
> +		type = "L2";
> +	}
> +
> +	if (flag) {
> +		void *sram_addr = sram_alloc_with_lsl(phdr->p_memsz, flag);
> +		if (sram_addr == NULL) {
> +			printk(KERN_ERR "elf_fdpic: not enough %s sram\n", type);
> +			return -ENOMEM;
> +		}
> +
> +		if (flag & L1_INST_SRAM)
> +			safe_dma_memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
> +		else
> +			memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
> +
> +		down_write(&mm->mmap_sem);
> +		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
> +		up_write(&mm->mmap_sem);
> +		*maddr = (unsigned long)sram_addr;
> +		*disp = 0;
> +	}
> +
> +	return 0;
> +}
> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index fdb66fa..1bad16c 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -1105,6 +1105,13 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
>  		    ELF_FDPIC_FLAG_CONTIGUOUS)
>  			load_addr += PAGE_ALIGN(phdr->p_memsz + disp);
>  
> +#ifndef ELF_FDPIC_PLAT_PROCESS_PHDR
> +# define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) 0
> +#endif
> +		ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr, &disp);
> +		if (ret)
> +			return ret;
> +
>  		seg->addr = maddr + disp;
>  		seg->p_vaddr = phdr->p_vaddr;
>  		seg->p_memsz = phdr->p_memsz;

-- 
------------------------------------------------------------------------
Greg Ungerer  --  Principal Engineer        EMAIL:     gerg@snapgear.com
SnapGear Group, McAfee                      PHONE:       +61 7 3435 2888
825 Stanley St,                             FAX:         +61 7 3891 3630
Woolloongabba, QLD, 4102, Australia         WEB: http://www.SnapGear.com

^ permalink raw reply	[flat|nested] 21+ messages in thread

* [PATCH] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
                   ` (3 preceding siblings ...)
  2009-06-15  1:43 ` Greg Ungerer
@ 2009-06-16  8:24 ` Mike Frysinger
  2009-06-23  5:32   ` Andrew Morton
  2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
  5 siblings, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2009-06-16  8:24 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Jie Zhang, Bernd Schmidt

From: Jie Zhang <jie.zhang@analog.com>

The Blackfin port has custom program header flags/addresses for
automatically loading regions into the dedicated on-chip SRAM.  So add a
hook for ports to leverage.

Signed-off-by: Jie Zhang <jie.zhang@analog.com>
Signed-off-by: Mike Frysinger <vapier@gentoo.org>
CC: Bernd Schmidt <bernds_cb1@t-online.de>
Acked-by: David Howells <dhowells@redhat.com>
Acked-by: Paul Mundt <lethal@linux-sh.org>
Acked-by: Greg Ungerer <gerg@uclinux.org>
---
Andrew: could you pick this up ?  same patch as before, just with the
additional tags added.

 arch/blackfin/include/asm/elf.h         |    8 +++
 arch/blackfin/kernel/Makefile           |    1 +
 arch/blackfin/kernel/binfmt_elf_fdpic.c |   80 +++++++++++++++++++++++++++++++
 fs/binfmt_elf_fdpic.c                   |    7 +++
 4 files changed, 96 insertions(+), 0 deletions(-)
 create mode 100644 arch/blackfin/kernel/binfmt_elf_fdpic.c

diff --git a/arch/blackfin/include/asm/elf.h b/arch/blackfin/include/asm/elf.h
index 230e160..aba2506 100644
--- a/arch/blackfin/include/asm/elf.h
+++ b/arch/blackfin/include/asm/elf.h
@@ -124,4 +124,12 @@ do {											\
 
 #define SET_PERSONALITY(ex) set_personality(PER_LINUX)
 
+struct mm_struct;
+struct elf_fdpic_params;
+struct elf32_phdr;
+extern int elf_fdpic_plat_process_phdr(struct mm_struct *, struct elf_fdpic_params *,
+                                       struct elf32_phdr *, unsigned long *, unsigned long *);
+#define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) \
+	elf_fdpic_plat_process_phdr(mm, params, phdr, maddr, disp)
+
 #endif
diff --git a/arch/blackfin/kernel/Makefile b/arch/blackfin/kernel/Makefile
index fd4d432..71c2291 100644
--- a/arch/blackfin/kernel/Makefile
+++ b/arch/blackfin/kernel/Makefile
@@ -15,6 +15,7 @@ else
     obj-y += time.o
 endif
 
+obj-$(CONFIG_BINFMT_ELF_FDPIC)       += binfmt_elf_fdpic.o
 obj-$(CONFIG_IPIPE)                  += ipipe.o
 obj-$(CONFIG_IPIPE_TRACE_MCOUNT)     += mcount.o
 obj-$(CONFIG_BFIN_GPTIMERS)          += gptimers.o
diff --git a/arch/blackfin/kernel/binfmt_elf_fdpic.c b/arch/blackfin/kernel/binfmt_elf_fdpic.c
new file mode 100644
index 0000000..d8192cf
--- /dev/null
+++ b/arch/blackfin/kernel/binfmt_elf_fdpic.c
@@ -0,0 +1,80 @@
+/*
+ * FDPIC ELF hooks
+ *
+ * Copyright (c) 2006-2009 Analog Devices Inc.
+ * Licensed under the GPL-2 or later.
+ */
+
+#include <linux/mm.h>
+#include <linux/elf.h>
+#include <linux/elf-fdpic.h>
+#include <linux/kernel.h>
+
+#include <asm/cacheflush.h>
+#include <asm/dma.h>
+
+int elf_fdpic_plat_process_phdr(struct mm_struct *mm,
+                                struct elf_fdpic_params *params,
+                                struct elf32_phdr *phdr,
+                                unsigned long *maddr, unsigned long *disp)
+{
+	/* 0xfeb00000, 0xfec00000, 0xff700000, 0xff800000, 0xff900000
+	 * and 0xffa00000 are also used in Dynamic linker and GNU ld.
+	 * They need to be kept synchronized.
+	 */
+	unsigned long flag = 0;
+	const char *type = NULL;
+
+	unsigned int e_flags = params->hdr.e_flags;
+	unsigned long p_vaddr = phdr->p_vaddr;
+	unsigned long p_flags = phdr->p_flags;
+
+	if (((e_flags & EF_BFIN_CODE_IN_L1) || p_vaddr == 0xffa00000) &&
+	    (p_flags & (PF_W | PF_X)) == PF_X)
+	{
+		flag = L1_INST_SRAM;
+		type = "L1 instruction";
+
+	} else if (((e_flags & EF_BFIN_DATA_IN_L1) ||
+	            p_vaddr == 0xff700000 ||
+	            p_vaddr == 0xff800000 ||
+	            p_vaddr == 0xff900000) &&
+	           (p_flags & (PF_X | PF_W)) == PF_W)
+	{
+		if (p_vaddr == 0xff800000) {
+			flag = L1_DATA_A_SRAM;
+			type = "L1 Data A";
+		} else if (p_vaddr == 0xff900000) {
+			flag = L1_DATA_B_SRAM;
+			type = "L1 Data B";
+		} else {
+			flag = L1_DATA_SRAM;
+			type = "L1 Data";
+		}
+
+	} else if (p_vaddr == 0xfeb00000 || p_vaddr == 0xfec00000) {
+		flag = L2_SRAM;
+		type = "L2";
+	}
+
+	if (flag) {
+		void *sram_addr = sram_alloc_with_lsl(phdr->p_memsz, flag);
+		if (sram_addr == NULL) {
+			printk(KERN_ERR "elf_fdpic: not enough %s sram\n", type);
+			return -ENOMEM;
+		}
+
+		if (flag & L1_INST_SRAM)
+			safe_dma_memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
+		else
+			memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
+
+		down_write(&mm->mmap_sem);
+		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
+		up_write(&mm->mmap_sem);
+		*maddr = (unsigned long)sram_addr;
+		*disp = 0;
+	}
+
+	return 0;
+}
diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
index fdb66fa..1bad16c 100644
--- a/fs/binfmt_elf_fdpic.c
+++ b/fs/binfmt_elf_fdpic.c
@@ -1105,6 +1105,13 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
 		    ELF_FDPIC_FLAG_CONTIGUOUS)
 			load_addr += PAGE_ALIGN(phdr->p_memsz + disp);
 
+#ifndef ELF_FDPIC_PLAT_PROCESS_PHDR
+# define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) 0
+#endif
+		ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr, &disp);
+		if (ret)
+			return ret;
+
 		seg->addr = maddr + disp;
 		seg->p_vaddr = phdr->p_vaddr;
 		seg->p_memsz = phdr->p_memsz;
-- 
1.6.3.1


^ permalink raw reply related	[flat|nested] 21+ messages in thread

* Re: [PATCH] FDPIC: add hook for arches to customize program header parsing
  2009-06-16  8:24 ` [PATCH] " Mike Frysinger
@ 2009-06-23  5:32   ` Andrew Morton
  2009-06-23 11:04     ` Mike Frysinger
  0 siblings, 1 reply; 21+ messages in thread
From: Andrew Morton @ 2009-06-23  5:32 UTC (permalink / raw)
  To: Mike Frysinger; +Cc: linux-kernel, Jie Zhang, Bernd Schmidt

On Tue, 16 Jun 2009 04:24:48 -0400 Mike Frysinger <vapier@gentoo.org> wrote:

> From: Jie Zhang <jie.zhang@analog.com>
> 
> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.
> 
> Signed-off-by: Jie Zhang <jie.zhang@analog.com>
> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
> CC: Bernd Schmidt <bernds_cb1@t-online.de>
> Acked-by: David Howells <dhowells@redhat.com>
> Acked-by: Paul Mundt <lethal@linux-sh.org>
> Acked-by: Greg Ungerer <gerg@uclinux.org>
> ---
> Andrew: could you pick this up ?  same patch as before, just with the
> additional tags added.
> 

I suppose we want to squeeze this into 2.6.31.

> diff --git a/arch/blackfin/include/asm/elf.h b/arch/blackfin/include/asm/elf.h
> index 230e160..aba2506 100644
> --- a/arch/blackfin/include/asm/elf.h
> +++ b/arch/blackfin/include/asm/elf.h
> @@ -124,4 +124,12 @@ do {											\
>  
>  #define SET_PERSONALITY(ex) set_personality(PER_LINUX)
>  
> +struct mm_struct;
> +struct elf_fdpic_params;
> +struct elf32_phdr;
> +extern int elf_fdpic_plat_process_phdr(struct mm_struct *, struct elf_fdpic_params *,
> +                                       struct elf32_phdr *, unsigned long *, unsigned long *);
> +#define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) \
> +	elf_fdpic_plat_process_phdr(mm, params, phdr, maddr, disp)
> +
>  #endif
> diff --git a/arch/blackfin/kernel/Makefile b/arch/blackfin/kernel/Makefile
> index fd4d432..71c2291 100644
> --- a/arch/blackfin/kernel/Makefile
> +++ b/arch/blackfin/kernel/Makefile
> @@ -15,6 +15,7 @@ else
>      obj-y += time.o
>  endif
>  
> +obj-$(CONFIG_BINFMT_ELF_FDPIC)       += binfmt_elf_fdpic.o
>  obj-$(CONFIG_IPIPE)                  += ipipe.o
>  obj-$(CONFIG_IPIPE_TRACE_MCOUNT)     += mcount.o
>  obj-$(CONFIG_BFIN_GPTIMERS)          += gptimers.o
> diff --git a/arch/blackfin/kernel/binfmt_elf_fdpic.c b/arch/blackfin/kernel/binfmt_elf_fdpic.c
> new file mode 100644
> index 0000000..d8192cf
> --- /dev/null
> +++ b/arch/blackfin/kernel/binfmt_elf_fdpic.c
> @@ -0,0 +1,80 @@
> +/*
> + * FDPIC ELF hooks
> + *
> + * Copyright (c) 2006-2009 Analog Devices Inc.
> + * Licensed under the GPL-2 or later.
> + */
> +
> +#include <linux/mm.h>
> +#include <linux/elf.h>
> +#include <linux/elf-fdpic.h>
> +#include <linux/kernel.h>
> +
> +#include <asm/cacheflush.h>
> +#include <asm/dma.h>
> +
> +int elf_fdpic_plat_process_phdr(struct mm_struct *mm,
> +                                struct elf_fdpic_params *params,
> +                                struct elf32_phdr *phdr,
> +                                unsigned long *maddr, unsigned long *disp)
> +{
> +	/* 0xfeb00000, 0xfec00000, 0xff700000, 0xff800000, 0xff900000
> +	 * and 0xffa00000 are also used in Dynamic linker and GNU ld.
> +	 * They need to be kept synchronized.
> +	 */
> +	unsigned long flag = 0;
> +	const char *type = NULL;
> +
> +	unsigned int e_flags = params->hdr.e_flags;
> +	unsigned long p_vaddr = phdr->p_vaddr;
> +	unsigned long p_flags = phdr->p_flags;
> +
> +	if (((e_flags & EF_BFIN_CODE_IN_L1) || p_vaddr == 0xffa00000) &&
> +	    (p_flags & (PF_W | PF_X)) == PF_X)
> +	{
> +		flag = L1_INST_SRAM;
> +		type = "L1 instruction";
> +
> +	} else if (((e_flags & EF_BFIN_DATA_IN_L1) ||
> +	            p_vaddr == 0xff700000 ||
> +	            p_vaddr == 0xff800000 ||
> +	            p_vaddr == 0xff900000) &&
> +	           (p_flags & (PF_X | PF_W)) == PF_W)
> +	{
> +		if (p_vaddr == 0xff800000) {
> +			flag = L1_DATA_A_SRAM;
> +			type = "L1 Data A";
> +		} else if (p_vaddr == 0xff900000) {
> +			flag = L1_DATA_B_SRAM;
> +			type = "L1 Data B";
> +		} else {
> +			flag = L1_DATA_SRAM;
> +			type = "L1 Data";
> +		}
> +
> +	} else if (p_vaddr == 0xfeb00000 || p_vaddr == 0xfec00000) {
> +		flag = L2_SRAM;
> +		type = "L2";
> +	}
> +
> +	if (flag) {
> +		void *sram_addr = sram_alloc_with_lsl(phdr->p_memsz, flag);
> +		if (sram_addr == NULL) {
> +			printk(KERN_ERR "elf_fdpic: not enough %s sram\n", type);
> +			return -ENOMEM;
> +		}
> +
> +		if (flag & L1_INST_SRAM)
> +			safe_dma_memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
> +		else
> +			memcpy(sram_addr, (const void *)(*maddr + *disp), phdr->p_memsz);
> +
> +		down_write(&mm->mmap_sem);
> +		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
> +		up_write(&mm->mmap_sem);
> +		*maddr = (unsigned long)sram_addr;
> +		*disp = 0;
> +	}
> +
> +	return 0;
> +}

blah.  Is this a checkpatch stress test or what?

Geeze.

> diff --git a/fs/binfmt_elf_fdpic.c b/fs/binfmt_elf_fdpic.c
> index fdb66fa..1bad16c 100644
> --- a/fs/binfmt_elf_fdpic.c
> +++ b/fs/binfmt_elf_fdpic.c
> @@ -1105,6 +1105,13 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
>  		    ELF_FDPIC_FLAG_CONTIGUOUS)
>  			load_addr += PAGE_ALIGN(phdr->p_memsz + disp);
>  
> +#ifndef ELF_FDPIC_PLAT_PROCESS_PHDR
> +# define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) 0
> +#endif
> +		ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr, &disp);
> +		if (ret)
> +			return ret;
> +

Wouldn't it be simpler to do

#ifdef ELF_FDPIC_PLAT_PROCESS_PHDR
		ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr,
						  &disp);
		if (ret)
			return ret;
#endif

?

If there's any prospect that we'll use ELF_FDPIC_PLAT_PROCESS_PHDR() a
second time from within this file then yes, adding a definition as
you did is appropriate.  But it should be near the top of the file, not
stuck stupidly in the middle of a C function.


^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [PATCH] FDPIC: add hook for arches to customize program header  parsing
  2009-06-23  5:32   ` Andrew Morton
@ 2009-06-23 11:04     ` Mike Frysinger
  0 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2009-06-23 11:04 UTC (permalink / raw)
  To: Andrew Morton; +Cc: linux-kernel, Jie Zhang, Bernd Schmidt

On Tue, Jun 23, 2009 at 01:32, Andrew Morton wrote:
> On Tue, 16 Jun 2009 04:24:48 -0400 Mike Frysinger wrote:
>> From: Jie Zhang <jie.zhang@analog.com>
>> The Blackfin port has custom program header flags/addresses for
>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>> hook for ports to leverage.
>>
>> Signed-off-by: Jie Zhang <jie.zhang@analog.com>
>> Signed-off-by: Mike Frysinger <vapier@gentoo.org>
>> CC: Bernd Schmidt <bernds_cb1@t-online.de>
>> Acked-by: David Howells <dhowells@redhat.com>
>> Acked-by: Paul Mundt <lethal@linux-sh.org>
>> Acked-by: Greg Ungerer <gerg@uclinux.org>
>> ---
>> Andrew: could you pick this up ?  same patch as before, just with the
>> additional tags added.
>
> I suppose we want to squeeze this into 2.6.31.

would be nice, but not terribly critical

>> --- a/fs/binfmt_elf_fdpic.c
>> +++ b/fs/binfmt_elf_fdpic.c
>> @@ -1105,6 +1105,13 @@ static int elf_fdpic_map_file_by_direct_mmap(struct elf_fdpic_params *params,
>>                   ELF_FDPIC_FLAG_CONTIGUOUS)
>>                       load_addr += PAGE_ALIGN(phdr->p_memsz + disp);
>>
>> +#ifndef ELF_FDPIC_PLAT_PROCESS_PHDR
>> +# define ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, maddr, disp) 0
>> +#endif
>> +             ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr, &disp);
>> +             if (ret)
>> +                     return ret;
>> +
>
> Wouldn't it be simpler to do
>
> #ifdef ELF_FDPIC_PLAT_PROCESS_PHDR
>                ret = ELF_FDPIC_PLAT_PROCESS_PHDR(mm, params, phdr, &maddr,
>                                                  &disp);
>                if (ret)
>                        return ret;
> #endif
>
> ?
>
> If there's any prospect that we'll use ELF_FDPIC_PLAT_PROCESS_PHDR() a
> second time from within this file then yes, adding a definition as
> you did is appropriate.  But it should be near the top of the file, not
> stuck stupidly in the middle of a C function.

the purpose was to stick to current conventions used in the file and
to maximize the amount of code compiled.  i dont particularly care wrt
the method used here.
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
                   ` (4 preceding siblings ...)
  2009-06-16  8:24 ` [PATCH] " Mike Frysinger
@ 2009-12-04 17:44 ` David Howells
  2009-12-05  0:28   ` Jie Zhang
                     ` (2 more replies)
  5 siblings, 3 replies; 21+ messages in thread
From: David Howells @ 2009-12-04 17:44 UTC (permalink / raw)
  To: uClinux development list
  Cc: dhowells, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

Mike Frysinger <vapier@gentoo.org> wrote:

> The Blackfin port has custom program header flags/addresses for
> automatically loading regions into the dedicated on-chip SRAM.  So add a
> hook for ports to leverage.

Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not against
the general concept, but:

> +		do_munmap(mm, *maddr, phdr->p_memsz + *disp);

There needs to be a mapping covering the SRAM region for the purposes of the
debugger.  Do you have a chardev covering the SRAM device?  Perhaps through
MTD?

David

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
@ 2009-12-05  0:28   ` Jie Zhang
  2009-12-07  3:27     ` [Uclinux-dist-devel] " Zhang, Sonic
  2009-12-07 10:10     ` Mike Frysinger
  2009-12-05 15:14   ` David Howells
  2009-12-07 10:10   ` Mike Frysinger
  2 siblings, 2 replies; 21+ messages in thread
From: Jie Zhang @ 2009-12-05  0:28 UTC (permalink / raw)
  To: David Howells
  Cc: uClinux development list, linux-kernel, Greg Ungerer,
	uclinux-dist-devel, David McCullough

On 12/05/2009 01:44 AM, David Howells wrote:
> Mike Frysinger<vapier@gentoo.org>  wrote:
>
>> The Blackfin port has custom program header flags/addresses for
>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>> hook for ports to leverage.
>
> Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not against
> the general concept, but:
>
>> +		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
>
> There needs to be a mapping covering the SRAM region for the purposes of the

Our GDB is still lack of the feature to debug applications using SRAM. 
So this part of code was not got exercised. So if we remove this line, 
can this patch got merged?

> debugger.  Do you have a chardev covering the SRAM device?  Perhaps through
> MTD?
>
Sorry, I don't know the answer to these two questions.


Jie



^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
  2009-12-05  0:28   ` Jie Zhang
@ 2009-12-05 15:14   ` David Howells
  2009-12-07 10:09     ` Mike Frysinger
  2009-12-07 10:10   ` Mike Frysinger
  2 siblings, 1 reply; 21+ messages in thread
From: David Howells @ 2009-12-05 15:14 UTC (permalink / raw)
  To: Jie Zhang
  Cc: dhowells, uClinux development list, linux-kernel, Greg Ungerer,
	uclinux-dist-devel, David McCullough

Jie Zhang <jie.zhang@analog.com> wrote:

> > There needs to be a mapping covering the SRAM region for the purposes of the
> 
> Our GDB is still lack of the feature to debug applications using SRAM. So this
> part of code was not got exercised. So if we remove this line, can this patch
> got merged?

No.  Firstly, the piece of storage that gets munmapped isn't used, so unmapping
it isn't wrong.  What you need to do is to put a mapping over the bit of the
SRAM you wish to use and then fill it and use it.  Ideally, you'd do this
inside of do_mmap_pgoff() - that way those bits of the SRAM can be shared, but
I'm not sure how best to do that.

But you need to stick a VMA over it so that various checks don't spit
EFAULT/EIO at you.

David

^ permalink raw reply	[flat|nested] 21+ messages in thread

* RE: [Uclinux-dist-devel] [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-12-05  0:28   ` Jie Zhang
@ 2009-12-07  3:27     ` Zhang, Sonic
  2009-12-07 10:10     ` Mike Frysinger
  1 sibling, 0 replies; 21+ messages in thread
From: Zhang, Sonic @ 2009-12-07  3:27 UTC (permalink / raw)
  To: Jie Zhang, David Howells
  Cc: uclinux-dist-devel, Greg Ungerer, uClinux development list,
	David McCullough, linux-kernel

No. The sram device can not be accessed by any user space application.
The applications can only do malloc/free via system call.

Sonic 

-----Original Message-----
From: uclinux-dist-devel-bounces@blackfin.uclinux.org
[mailto:uclinux-dist-devel-bounces@blackfin.uclinux.org] On Behalf Of
Jie Zhang
Sent: Saturday, December 05, 2009 8:28 AM
To: David Howells
Cc: uclinux-dist-devel@blackfin.uclinux.org; Greg Ungerer; uClinux
development list; David McCullough; linux-kernel@vger.kernel.org
Subject: Re: [Uclinux-dist-devel] [uClinux-dev] [PATCH/RFC] FDPIC: add
hook for arches to customize program header parsing

On 12/05/2009 01:44 AM, David Howells wrote:
> Mike Frysinger<vapier@gentoo.org>  wrote:
>
>> The Blackfin port has custom program header flags/addresses for 
>> automatically loading regions into the dedicated on-chip SRAM.  So 
>> add a hook for ports to leverage.
>
> Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not

> against the general concept, but:
>
>> +		do_munmap(mm, *maddr, phdr->p_memsz + *disp);
>
> There needs to be a mapping covering the SRAM region for the purposes 
> of the

Our GDB is still lack of the feature to debug applications using SRAM. 
So this part of code was not got exercised. So if we remove this line,
can this patch got merged?

> debugger.  Do you have a chardev covering the SRAM device?  Perhaps 
> through MTD?
>
Sorry, I don't know the answer to these two questions.


Jie


_______________________________________________
Uclinux-dist-devel mailing list
Uclinux-dist-devel@blackfin.uclinux.org
https://blackfin.uclinux.org/mailman/listinfo/uclinux-dist-devel

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize  program header parsing
  2009-12-05 15:14   ` David Howells
@ 2009-12-07 10:09     ` Mike Frysinger
  0 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2009-12-07 10:09 UTC (permalink / raw)
  To: David Howells
  Cc: Jie Zhang, uClinux development list, linux-kernel, Greg Ungerer,
	uclinux-dist-devel, David McCullough

On Sat, Dec 5, 2009 at 10:14, David Howells wrote:
> Jie Zhang <jie.zhang@analog.com> wrote:
>> > There needs to be a mapping covering the SRAM region for the purposes of the
>>
>> Our GDB is still lack of the feature to debug applications using SRAM. So this
>> part of code was not got exercised. So if we remove this line, can this patch
>> got merged?
>
> No.  Firstly, the piece of storage that gets munmapped isn't used, so unmapping
> it isn't wrong.  What you need to do is to put a mapping over the bit of the
> SRAM you wish to use and then fill it and use it.  Ideally, you'd do this
> inside of do_mmap_pgoff() - that way those bits of the SRAM can be shared, but
> I'm not sure how best to do that.

we've looked into trying to represent the SRAM regions with normal
VMA's a few times, but i think the conclusion every time has been that
it isnt [currently] doable.  i vaguely recall it's due to the fact
that Blackfin SRAM is harvard based and VMA's cant cope with this
restriction.  Sonic should be able to provide more details though.

currently we have a simpler allocator for kernel/user space to
leverage so that small pieces can be dynamically allocated/freed.

> But you need to stick a VMA over it so that various checks don't spit
> EFAULT/EIO at you.

we give SRAM's a "pass" in every place where addresses are checked
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize  program header parsing
  2009-12-05  0:28   ` Jie Zhang
  2009-12-07  3:27     ` [Uclinux-dist-devel] " Zhang, Sonic
@ 2009-12-07 10:10     ` Mike Frysinger
  2009-12-07 10:17       ` Jie Zhang
  1 sibling, 1 reply; 21+ messages in thread
From: Mike Frysinger @ 2009-12-07 10:10 UTC (permalink / raw)
  To: Jie Zhang
  Cc: David Howells, uClinux development list, linux-kernel,
	Greg Ungerer, uclinux-dist-devel, David McCullough

On Fri, Dec 4, 2009 at 19:28, Jie Zhang <wrote:
> On 12/05/2009 01:44 AM, David Howells wrote:
>> Mike Frysinger<vapier@gentoo.org>  wrote:
>>> The Blackfin port has custom program header flags/addresses for
>>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>>> hook for ports to leverage.
>>
>> Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not
>> against
>> the general concept, but:
>>
>>> +               do_munmap(mm, *maddr, phdr->p_memsz + *disp);
>>
>> There needs to be a mapping covering the SRAM region for the purposes of
>> the
>
> Our GDB is still lack of the feature to debug applications using SRAM.

semi true.  L1 text appears to work fine:
(gdb) stepi
0xffa02aac in moo ()
(gdb) dis
Dump of assembler code from 0xffa02aac to 0xffa02aec:
0xffa02aac <moo+0>:     LINK 0xc;               /* (12) */
0xffa02ab0 <moo+4>:     [FP + 0x8] = R0;
....

but L1 data doesnt seem to work (probably something simple to fix in
our kernel ptrace?):
(gdb) print i
Cannot access memory at address 0xff803e58

the simple code:
int i __attribute__((l1_data));

> So this part of code was not got exercised. So if we remove this line, can
> this patch got merged?

this code does get exercised -- it's run every time code is loaded
from initramfs for example.  the
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize  program header parsing
  2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
  2009-12-05  0:28   ` Jie Zhang
  2009-12-05 15:14   ` David Howells
@ 2009-12-07 10:10   ` Mike Frysinger
  2 siblings, 0 replies; 21+ messages in thread
From: Mike Frysinger @ 2009-12-07 10:10 UTC (permalink / raw)
  To: David Howells
  Cc: uClinux development list, linux-kernel, Jie Zhang, Greg Ungerer,
	uclinux-dist-devel, David McCullough

On Fri, Dec 4, 2009 at 12:44, David Howells wrote:
> Mike Frysinger <vapier@gentoo.org> wrote:
>> The Blackfin port has custom program header flags/addresses for
>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>> hook for ports to leverage.
>
> Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not against
> the general concept, but:
>
>> +             do_munmap(mm, *maddr, phdr->p_memsz + *disp);
>
> There needs to be a mapping covering the SRAM region for the purposes of the
> debugger.  Do you have a chardev covering the SRAM device?  Perhaps through
> MTD?

SRAM is accessed directly by kernel/user space.  there is no device
indirection nor are there any mappings.
-mike

^ permalink raw reply	[flat|nested] 21+ messages in thread

* Re: [uClinux-dev] [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing
  2009-12-07 10:10     ` Mike Frysinger
@ 2009-12-07 10:17       ` Jie Zhang
  0 siblings, 0 replies; 21+ messages in thread
From: Jie Zhang @ 2009-12-07 10:17 UTC (permalink / raw)
  To: Mike Frysinger
  Cc: David Howells, uClinux development list, linux-kernel,
	Greg Ungerer, uclinux-dist-devel, David McCullough

On 12/07/2009 06:10 PM, Mike Frysinger wrote:
> On Fri, Dec 4, 2009 at 19:28, Jie Zhang<wrote:
>> On 12/05/2009 01:44 AM, David Howells wrote:
>>> Mike Frysinger<vapier@gentoo.org>    wrote:
>>>> The Blackfin port has custom program header flags/addresses for
>>>> automatically loading regions into the dedicated on-chip SRAM.  So add a
>>>> hook for ports to leverage.
>>>
>>> Now that I've ACK'd this, I feel I'm going to have to NAK it.  I'm not
>>> against
>>> the general concept, but:
>>>
>>>> +               do_munmap(mm, *maddr, phdr->p_memsz + *disp);
>>>
>>> There needs to be a mapping covering the SRAM region for the purposes of
>>> the
>>
>> Our GDB is still lack of the feature to debug applications using SRAM.
>
> semi true.  L1 text appears to work fine:

This is by lucky. We need some feature in GDB 7.0 to cope with code or 
data in L1 SRAM.


Jie

^ permalink raw reply	[flat|nested] 21+ messages in thread

end of thread, other threads:[~2009-12-07 10:17 UTC | newest]

Thread overview: 21+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-06-13  1:01 [PATCH/RFC] FDPIC: add hook for arches to customize program header parsing Mike Frysinger
2009-06-13 12:23 ` [uClinux-dev] " David Howells
2009-06-13 16:13 ` Jamie Lokier
2009-06-13 16:40   ` Mike Frysinger
2009-06-13 18:25     ` Jamie Lokier
2009-06-13 18:26       ` Jamie Lokier
2009-06-14  0:32       ` Mike Frysinger
2009-06-14  0:42         ` Jie Zhang
2009-06-14  9:43 ` Paul Mundt
2009-06-15  1:43 ` Greg Ungerer
2009-06-16  8:24 ` [PATCH] " Mike Frysinger
2009-06-23  5:32   ` Andrew Morton
2009-06-23 11:04     ` Mike Frysinger
2009-12-04 17:44 ` [uClinux-dev] [PATCH/RFC] " David Howells
2009-12-05  0:28   ` Jie Zhang
2009-12-07  3:27     ` [Uclinux-dist-devel] " Zhang, Sonic
2009-12-07 10:10     ` Mike Frysinger
2009-12-07 10:17       ` Jie Zhang
2009-12-05 15:14   ` David Howells
2009-12-07 10:09     ` Mike Frysinger
2009-12-07 10:10   ` Mike Frysinger

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.