Re: [PATCH] DMA : Added DMA API for Raspberrypi

2016-08-25 Thread Pavel Pisa 
Hello Mudit Jain,

I have tried to test the DMA API code

I have setup temporary branch on my RTEMS tests repo

  https://github.com/ppisa/rtems/tree/rtems-rpi-devel-dma-test

I have applied patches extracted from your GitHub repository

  Re: [PATCH] Mailbox : Extending functionality
  https://github.com/ppisa/rtems/commit/640071d0e16f0a29019e09c0308a364373b4b0e1

with changes in alignment and padding which I have described
in review

  [PATCH] DMA : Added DMA API for Raspberrypi
  https://github.com/ppisa/rtems/commit/d1f1ed30f918789b3ed91771ab743c7a1e6bf649

I have added missing defines to
  c/src/lib/libbsp/arm/raspberrypi/include/irq.h
which has been probably lost during your rebasing to master.
Without these code cannot compile.

My patches

  arm/raspberrypi: DMA API: correct obvious errors 
  https://github.com/ppisa/rtems/commit/ec34b48b9b87462276f93ab07f7522b84c1819bd

Correct your code to at least initialization call suceed

  arm/raspberrypi: DMA API: ensure that channel is enabled when it is 
configured.
  https://github.com/ppisa/rtems/commit/ec34b48b9b87462276f93ab07f7522b84c1819bd

 Because even after above correction I have not observed channel activity,
 I have added code to ensure that channel is enabled in a global enable 
register  

  arm/raspberrypi: DMA API: add simple memory to memory transfer test
  https://github.com/ppisa/rtems/commit/6c7d9463c83ee2d084a88235dbdaabd32b60b1a0

Quite dirty test integrated into RTEMS samples ticker application
to check if DMA API works.

System does not crash/stuck during testing, operations returns success status
but even after more ticks there data do not appear in destination position
albeit DMA request 0 should be permanently assigned according to the manual
so data should be copied.

rpi_dma_init ...
rpi_dma_init 0
rpi_dma_allocate ...
rpi_dma_allocate 0
rpi_dma_setup_src ...
rpi_dma_setup_src 0
rpi_dma_setup_dst ...
rpi_dma_setup_dst 0
rpi_dma_setup_intr ...
rpi_dma_setup_intr 0
rpi_dma_start ...
rpi_dma_start 0

dma test result
11>00 22>00 33>00 44>00 55>00 66>00 77>00 88>00 
simple mem2mem DMA test has FAILED

It is important that at least some functional tests
run to prove that code development heads in the right
direction.

Please, check if I use API intended way and try to help us
to make code more acceptable for mainline. We need to
declare the state for project evaluation forms.

See see remarks inlined in the following DMA patch


On Saturday 20 of August 2016 17:33:18 Mudit Jain wrote:
> Brief API Description
>
>  rpi_dma_init -> Initializes the channel structure
>  and its members for that particular channel, gets
>  the physical address of the control block structure
>  and installs the interrupt handler.
>
>  rpi_dma_allocate -> Allocates the channel if it is
>  not busy
>
>  rpi_dma_setup_dst & rpi_dma_setup_src -> These setup
>  src and dst parameters like dreq, width. Basically they
>  configure the info section of the control block structure
>  of that particular channel.
>
>  rpi_dma_setup_intr -> These will assign the handler
>  function for channel interrupt. This basically again
>  updates the channel structure with that function.
>  Note : rpi_dma_intr is the callback function for the
>  interrupt controller and calls this function internally.
>
>  rpi_dma_start -> Here you provide the virtual address,
>  the channel to be used and the width. Internally, it
>  converts the address to physical address and configures
>  the control block for that channel.
>  It flushes and invalidates the cache and writes the physical
>  address of the control block to a particular register
>  corresponding to the channel.
>
>  rpi_dma_free -> Frees the channel
> ---
>  c/src/lib/libbsp/arm/raspberrypi/Makefile.am   |   4 +
>  c/src/lib/libbsp/arm/raspberrypi/include/dma.h | 200 
>  c/src/lib/libbsp/arm/raspberrypi/misc/dma.c| 618
> + 3 files changed, 822 insertions(+)
>  create mode 100644 c/src/lib/libbsp/arm/raspberrypi/include/dma.h
>  create mode 100644 c/src/lib/libbsp/arm/raspberrypi/misc/dma.c
>
> diff --git a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am index 4b111ad..5b0e92e
> 100644
> --- a/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> +++ b/c/src/lib/libbsp/arm/raspberrypi/Makefile.am
> @@ -51,6 +51,7 @@ include_bsp_HEADERS += include/rpi-gpio.h
>  include_bsp_HEADERS += include/i2c.h
>  include_bsp_HEADERS += include/spi.h
>  include_bsp_HEADERS += include/mailbox.h
> +include_bsp_HEADERS += include/dma.h
>  include_bsp_HEADERS += include/vc.h
>  include_bsp_HEADERS += include/rpi-fb.h
>  include_bsp_HEADERS += console/fbcons.h
> @@ -124,6 +125,9 @@ libbsp_a_SOURCES += console/fb.c
>  libbsp_a_SOURCES += console/fbcons.c
>  libbsp_a_SOURCES += console/outch.c
>
> +# DMA
> +libbsp_a_SOURCES += misc/dma.c
> +
>  # Mailbox
>  libbsp_a_SOURCES += misc/mailbox.c
>
> diff --git

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

2016-08-25 Thread Chris Johns 

Hi Pavel,

I am sorry about the delay. I have been on other things and then I was 
out with a pesky flue virus for the past week.


On 26/08/2016 03:47, Pavel Pisa wrote:

Hello Gedare,

On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote:

On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa  wrote:

   Is there some defined function/way to check if RTEMS executive
   reached switch to multitasking mode?


_System_state_Is_before_multitasking()


Thanks, great that is what I have been looking for.


This has impact to think about correct locking in functions
which are required to be used during startup when there is
no concurrent execution but mutexes support and memory initialization
is not finished yet but the same functions can be used later
when scheduler is running for further update of system state.

More complete analysis and context in previous communication.


I read prior discussion and had no problems, but Sebastian's concern
should be addressed whether other ARM targets are correct or not.


His (correct) concern has been about SMP.
But I think that need of locking has been eliminated by my previous commit.
There is another reason against locking by IRQ disable or spinlock.
If we consider update of pagetables at runtime where some real time tasks
run then if scheduler is blocked but change in large part of address space
then we can consider this as almost unbound latency source.

So I vote for no locking at this level at all and mutex based locking
(skipped if part of initialization and _System_state_Is_before_multitasking)
at higher level when concurrent use need arises - for example allocation
of virtual address space for mmap or something similar.



Great. I was hoping you would provide a clear decision. I agree. I will 
remove the interrupt mask and push the change.


Thanks for posts and the detail. It is really valuable.

Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

2016-08-25 Thread Gedare Bloom 
On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa  wrote:
> Hello Chris and others,
>
> I would like to remind Chris's patches (top-post to highlight important the 
> first)
>
>   [PATCH v2 1/2] arm/cortex-a: Fix cache flush/invalidate after u-boot.
>   [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable 
> calls.
>
> I consider fix of Zynq (all arm-a9mpcore-start) boot
> through U-boot as important. But discussion has vanished.
>
> From my point of view, changes should/could be committed
> as they are. I consider locking in this place as unimportant
> in actual state (see my previous analysis in the thread) so
> the second patch can even replace rtems_interrupt_disable by comment
>
> -   rtems_interrupt_disable(level);
> +   /* FIXME: if concurrent update of same area is considered locking hat to 
> be added */
>
> or even remove lines alltogether. The real need for locking
> has been eliminated by my previous patch
>
>   bsps/arm: do not disable MMU during translation table management operations.
>
> because set_translation_table_entries() manipulated with global core state 
> before.
> It disabled cache and after update re-enabled it. Interleaving parallel 
> execution
> of this sequence would lead to errors for sure. As I have analyzed, that 
> sequence has
> been probably broken for SMP at all because invalidation complete cache
> (only realizable by set and way on ARMv7) can be implemented without 
> broadcast to snoop
> subsystem on some cores so only reliable way is to ask all CPUs by IPI to 
> stop,
> then run complete cache flush on each core one by one. But that is not case 
> for now,
> so locking is not required except for case of contention for given region and 
> this
> has to be solved somewhere else.
>
> So at the end, I suggest to remove locking alltogether there.
>
> There has been left my question unanswered
>
>   Is there some defined function/way to check if RTEMS executive
>   reached switch to multitasking mode?
>
_System_state_Is_before_multitasking()

> This has impact to think about correct locking in functions
> which are required to be used during startup when there is
> no concurrent execution but mutexes support and memory initialization
> is not finished yet but the same functions can be used later
> when scheduler is running for further update of system state.
>
> More complete analysis and context in previous communication.
>
I read prior discussion and had no problems, but Sebastian's concern
should be addressed whether other ARM targets are correct or not.

> Best wishes,
>
>   Pavel
>
>
> On Tuesday 16 of August 2016 15:28:42 Pavel Pisa wrote:
>> Hello Chris and Sebastian,
>>
>> On Tuesday 16 of August 2016 07:55:57 Sebastian Huber wrote:
>> > On 16/08/16 07:45, Chris Johns wrote:
>> > > ---
>> > >   c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 4 ++--
>> > >   1 file changed, 2 insertions(+), 2 deletions(-)
>> > >
>> > > diff --git a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
>> > > b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c index
>> > > f650009..cfad45f 100644
>> > > --- a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
>> > > +++ b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
>> > > @@ -88,10 +88,10 @@ uint32_t arm_cp15_set_translation_table_entries(
>> > > rtems_interrupt_level level;
>> > > uint32_t section_flags_of_first_entry;
>> > >
>> > > -  rtems_interrupt_disable(level);
>> > > +  rtems_interrupt_local_disable(level);
>> > > section_flags_of_first_entry =
>> > >   set_translation_table_entries(begin, end, section_flags);
>> > > -  rtems_interrupt_enable(level);
>> > > +  rtems_interrupt_local_enable(level);
>> > >
>> > > return section_flags_of_first_entry;
>> > >   }
>> >
>> > We should only change this if this is known to work on SMP.
>>
>> My analysis for this concrete case,
>>
>> 1) RTEMS uses same MMU table for all CPUs.
>> 2) inner set_translation_table_entries() ensures that change
>>is visible to all CPUs
>> 3) when arm_cp15_set_translation_table_entries() is called for range
>>which is not (yet) accessed by other CPU(s) then the function should
>>not cause any breakage
>> 4) when change is requested for same range in parallel/twice from multiple
>>threads or even CPUs then  it is indication of some more serious problem
>>in upper layers
>> 5) if the update of mapping is requested for some range from cached to
>>uncached for example then it is not enough to protect
>>arm_cp15_set_translation_table_entries() alone. Protection
>>of necessary cache flush and invalidation is required in addition.
>>
>>
>> So generally, there is almost no difference between case when there is
>> no protection or weak protection by rtems_interrupt_local_disable().
>> May it be that there can be some difference if operation
>> ttb [i] = addr | section_flags;
>> is translated by multiple memory accesses by C compiler

Re: FYI - RSB tools and binutils 2.27

2016-08-25 Thread Gedare Bloom 
P.S. you may like to see if there is a recent newlib snapshot
available or request one.

On Thu, Aug 25, 2016 at 3:29 PM, Gedare Bloom  wrote:
> Sebastian has more than once suggested we bump to gcc6 snapshot
>
> On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill  wrote:
>> Hi
>>
>> Just a note that I am testing updating the binutils version to this now.
>>
>> Is there a gcc bump needed also?
>>
>> --joel
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: FYI - RSB tools and binutils 2.27

2016-08-25 Thread Gedare Bloom 
Sebastian has more than once suggested we bump to gcc6 snapshot

On Thu, Aug 25, 2016 at 3:27 PM, Joel Sherrill  wrote:
> Hi
>
> Just a note that I am testing updating the binutils version to this now.
>
> Is there a gcc bump needed also?
>
> --joel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

FYI - RSB tools and binutils 2.27

2016-08-25 Thread Joel Sherrill 
Hi

Just a note that I am testing updating the binutils version to this now.

Is there a gcc bump needed also?

--joel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

2016-08-25 Thread Gedare Bloom 
On Thu, Aug 25, 2016 at 1:47 PM, Pavel Pisa  wrote:
> Hello Gedare,
>
> On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote:
>> On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa  wrote:
>> >   Is there some defined function/way to check if RTEMS executive
>> >   reached switch to multitasking mode?
>>
>> _System_state_Is_before_multitasking()
>
> Thanks, great that is what I have been looking for.
>
>> > This has impact to think about correct locking in functions
>> > which are required to be used during startup when there is
>> > no concurrent execution but mutexes support and memory initialization
>> > is not finished yet but the same functions can be used later
>> > when scheduler is running for further update of system state.
>> >
>> > More complete analysis and context in previous communication.
>>
>> I read prior discussion and had no problems, but Sebastian's concern
>> should be addressed whether other ARM targets are correct or not.
>
> His (correct) concern has been about SMP.
> But I think that need of locking has been eliminated by my previous commit.
> There is another reason against locking by IRQ disable or spinlock.
> If we consider update of pagetables at runtime where some real time tasks
> run then if scheduler is blocked but change in large part of address space
> then we can consider this as almost unbound latency source.
>
> So I vote for no locking at this level at all and mutex based locking
> (skipped if part of initialization and _System_state_Is_before_multitasking)
> at higher level when concurrent use need arises - for example allocation
> of virtual address space for mmap or something similar.
>
This seems reasonable to me. I expect to eventually add some (limited)
capabilities in this direction but I have not finished any (mental)
design.

> Best wishes,
>
>  Pavel
>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

2016-08-25 Thread Pavel Pisa 
Hello Gedare,

On Thursday 25 of August 2016 17:32:09 Gedare Bloom wrote:
> On Thu, Aug 25, 2016 at 6:56 AM, Pavel Pisa  wrote:
> >   Is there some defined function/way to check if RTEMS executive
> >   reached switch to multitasking mode?
>
> _System_state_Is_before_multitasking()

Thanks, great that is what I have been looking for.

> > This has impact to think about correct locking in functions
> > which are required to be used during startup when there is
> > no concurrent execution but mutexes support and memory initialization
> > is not finished yet but the same functions can be used later
> > when scheduler is running for further update of system state.
> >
> > More complete analysis and context in previous communication.
>
> I read prior discussion and had no problems, but Sebastian's concern
> should be addressed whether other ARM targets are correct or not.

His (correct) concern has been about SMP.
But I think that need of locking has been eliminated by my previous commit.
There is another reason against locking by IRQ disable or spinlock.
If we consider update of pagetables at runtime where some real time tasks
run then if scheduler is blocked but change in large part of address space
then we can consider this as almost unbound latency source.

So I vote for no locking at this level at all and mutex based locking
(skipped if part of initialization and _System_state_Is_before_multitasking)
at higher level when concurrent use need arises - for example allocation
of virtual address space for mmap or something similar.

Best wishes,

 Pavel


___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel

Re: [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

2016-08-25 Thread Pavel Pisa 
Hello Chris and others,

I would like to remind Chris's patches (top-post to highlight important the 
first)

  [PATCH v2 1/2] arm/cortex-a: Fix cache flush/invalidate after u-boot.
  [PATCH v2 2/2] libbsp/arm: Fix the local interrupt mask disable/enable calls.

I consider fix of Zynq (all arm-a9mpcore-start) boot
through U-boot as important. But discussion has vanished.

>From my point of view, changes should/could be committed
as they are. I consider locking in this place as unimportant
in actual state (see my previous analysis in the thread) so
the second patch can even replace rtems_interrupt_disable by comment

-   rtems_interrupt_disable(level);
+   /* FIXME: if concurrent update of same area is considered locking hat to be 
added */

or even remove lines alltogether. The real need for locking
has been eliminated by my previous patch

  bsps/arm: do not disable MMU during translation table management operations.

because set_translation_table_entries() manipulated with global core state 
before.
It disabled cache and after update re-enabled it. Interleaving parallel 
execution
of this sequence would lead to errors for sure. As I have analyzed, that 
sequence has
been probably broken for SMP at all because invalidation complete cache
(only realizable by set and way on ARMv7) can be implemented without broadcast 
to snoop
subsystem on some cores so only reliable way is to ask all CPUs by IPI to stop,
then run complete cache flush on each core one by one. But that is not case for 
now,
so locking is not required except for case of contention for given region and 
this
has to be solved somewhere else.

So at the end, I suggest to remove locking alltogether there.

There has been left my question unanswered

  Is there some defined function/way to check if RTEMS executive
  reached switch to multitasking mode?

This has impact to think about correct locking in functions
which are required to be used during startup when there is
no concurrent execution but mutexes support and memory initialization
is not finished yet but the same functions can be used later
when scheduler is running for further update of system state.

More complete analysis and context in previous communication.

Best wishes,

  Pavel


On Tuesday 16 of August 2016 15:28:42 Pavel Pisa wrote:
> Hello Chris and Sebastian,
>
> On Tuesday 16 of August 2016 07:55:57 Sebastian Huber wrote:
> > On 16/08/16 07:45, Chris Johns wrote:
> > > ---
> > >   c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c | 4 ++--
> > >   1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
> > > b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c index
> > > f650009..cfad45f 100644
> > > --- a/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
> > > +++ b/c/src/lib/libbsp/arm/shared/arm-cp15-set-ttb-entries.c
> > > @@ -88,10 +88,10 @@ uint32_t arm_cp15_set_translation_table_entries(
> > > rtems_interrupt_level level;
> > > uint32_t section_flags_of_first_entry;
> > >
> > > -  rtems_interrupt_disable(level);
> > > +  rtems_interrupt_local_disable(level);
> > > section_flags_of_first_entry =
> > >   set_translation_table_entries(begin, end, section_flags);
> > > -  rtems_interrupt_enable(level);
> > > +  rtems_interrupt_local_enable(level);
> > >
> > > return section_flags_of_first_entry;
> > >   }
> >
> > We should only change this if this is known to work on SMP.
>
> My analysis for this concrete case,
>
> 1) RTEMS uses same MMU table for all CPUs.
> 2) inner set_translation_table_entries() ensures that change
>is visible to all CPUs
> 3) when arm_cp15_set_translation_table_entries() is called for range
>which is not (yet) accessed by other CPU(s) then the function should
>not cause any breakage
> 4) when change is requested for same range in parallel/twice from multiple
>threads or even CPUs then  it is indication of some more serious problem
>in upper layers
> 5) if the update of mapping is requested for some range from cached to
>uncached for example then it is not enough to protect
>arm_cp15_set_translation_table_entries() alone. Protection
>of necessary cache flush and invalidation is required in addition.
>
>
> So generally, there is almost no difference between case when there is
> no protection or weak protection by rtems_interrupt_local_disable().
> May it be that there can be some difference if operation
> ttb [i] = addr | section_flags;
> is translated by multiple memory accesses by C compiler (highly
> improbable).
>
> If the dynamic MMU operations/virtual space allocations are needed
> like in multiprocess OS then MMU table changes needs to be protected
> by spinlock or better semaphore (to not cause block of other tasks).
>
> So I agree that simple change of rtems_interrupt_disable(level)
> to rtems_interrupt_local_disable(level) is not perfect but on the other
> hand real situation is not changed.

[PATCH] testsuite: Add libdl/dl05 weak symbol test.

2016-08-25 Thread Chris Johns 
Requires rtems-tools to be updated.
---
 testsuites/libtests/Makefile.am  |  2 +-
 testsuites/libtests/configure.ac |  1 +
 testsuites/libtests/dl05/Makefile.am | 49 +
 testsuites/libtests/dl05/dl-load.c   | 49 +
 testsuites/libtests/dl05/dl-load.h   | 14 ++
 testsuites/libtests/dl05/dl-o5.c | 17 
 testsuites/libtests/dl05/dl05.doc| 25 +++
 testsuites/libtests/dl05/dl05.scn|  9 
 testsuites/libtests/dl05/init.c  | 82 
 9 files changed, 247 insertions(+), 1 deletion(-)
 create mode 100644 testsuites/libtests/dl05/Makefile.am
 create mode 100644 testsuites/libtests/dl05/dl-load.c
 create mode 100644 testsuites/libtests/dl05/dl-load.h
 create mode 100644 testsuites/libtests/dl05/dl-o5.c
 create mode 100644 testsuites/libtests/dl05/dl05.doc
 create mode 100644 testsuites/libtests/dl05/dl05.scn
 create mode 100644 testsuites/libtests/dl05/init.c

diff --git a/testsuites/libtests/Makefile.am b/testsuites/libtests/Makefile.am
index effed07..4925775 100644
--- a/testsuites/libtests/Makefile.am
+++ b/testsuites/libtests/Makefile.am
@@ -46,7 +46,7 @@ _SUBDIRS += syscall01
 endif
 
 if DLTESTS
-_SUBDIRS += dl01 dl02 dl03
+_SUBDIRS += dl01 dl02 dl03 dl05
 if HAS_CXX
 _SUBDIRS += dl04
 endif
diff --git a/testsuites/libtests/configure.ac b/testsuites/libtests/configure.ac
index 31afcae..9093cba 100644
--- a/testsuites/libtests/configure.ac
+++ b/testsuites/libtests/configure.ac
@@ -128,6 +128,7 @@ dl01/Makefile
 dl02/Makefile
 dl03/Makefile
 dl04/Makefile
+dl05/Makefile
 dumpbuf01/Makefile
 ftp01/Makefile
 gxx01/Makefile
diff --git a/testsuites/libtests/dl05/Makefile.am 
b/testsuites/libtests/dl05/Makefile.am
new file mode 100644
index 000..4aeea8a
--- /dev/null
+++ b/testsuites/libtests/dl05/Makefile.am
@@ -0,0 +1,49 @@
+rtems_tests_PROGRAMS = dl05
+dl05_SOURCES = init.c dl-load.c dl-tar.c dl-tar.h
+
+BUILT_SOURCES = dl-tar.c dl-tar.h
+
+dist_rtems_tests_DATA = dl05.scn dl05.doc
+
+include $(RTEMS_ROOT)/make/custom/@RTEMS_BSP@.cfg
+include $(top_srcdir)/../automake/compile.am
+include $(top_srcdir)/../automake/leaf.am
+
+AM_CPPFLAGS += -I$(top_srcdir)/../support/include
+
+LINK_OBJS = $(dl05_OBJECTS)
+LINK_LIBS = $(dl05_LDLIBS)
+
+dl-o1.o: dl-o5.c
+
+dl.tar: dl-o5.o
+   @rm -f $@
+   $(PAX) -w -f $@ $<
+CLEANFILES += dl.tar
+
+dl-tar.c: dl.tar
+   $(BIN2C) -C $< $@
+CLEANFILES += dl-tar.c
+
+dl-tar.h: dl.tar
+   $(BIN2C) -H $< $@
+CLEANFILES += dl-tar.h
+
+dl05.pre$(EXEEXT): $(dl05_OBJECTS) $(dl05_DEPENDENCIES)
+   @rm -f dl05.pre$(EXEEXT)
+   $(make-exe)
+   rm -f dl05.pre.ralf
+
+dl05.pre: dl05.pre$(EXEEXT)
+   mv $< $@
+CLEANFILES += dl05.pre
+
+dl-sym.o: dl05.pre
+   rtems-syms -e -c "$(CFLAGS)" -o $@ $<
+
+dl05$(EXEEXT):  $(dl05_OBJECTS) $(dl05_DEPENDENCIES) dl-sym.o
+   @rm -f dl05$(EXEEXT)
+   $(LINK.c) $(CPU_CFLAGS) $(AM_CFLAGS) $(AM_LDFLAGS) \
+   -o $(basename $@)$(EXEEXT) $(LINK_OBJS) dl-sym.o 
$(LINK_LIBS)
+
+include $(top_srcdir)/../automake/local.am
diff --git a/testsuites/libtests/dl05/dl-load.c 
b/testsuites/libtests/dl05/dl-load.c
new file mode 100644
index 000..3036a3a
--- /dev/null
+++ b/testsuites/libtests/dl05/dl-load.c
@@ -0,0 +1,49 @@
+/*
+ * Copyright (c) 2014 Chris Johns .  All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#include "tmacros.h"
+
+#include 
+
+#include 
+
+#include "dl-load.h"
+
+typedef int (*dl_call)(void);
+
+__attribute__((__weak__)) void base_func(const char *c);
+
+__attribute__((__weak__)) void base_func(const char *c)
+{
+  printf("base_func: %s", c);
+}
+
+int dl_load_test(void)
+{
+  void*   handle;
+  dl_call call;
+  int call_ret;
+  int unresolved;
+  char*   message = "loaded";
+
+  printf("load: /dl-o5.o\n");
+  rtems_test_assert((handle = dlopen ("/dl-o5.o", RTLD_NOW | RTLD_GLOBAL)) != 
NULL);
+  if (dlinfo (handle, RTLD_DI_UNRESOLVED, ) < 0)
+message = "dlinfo error checking unresolved status";
+  else if (unresolved)
+message = "has unresolved externals";
+  printf ("handle: %p %s\n", handle, message);
+  rtems_test_assert(unresolved == 0);
+  base_func("Called from " __FILE__ ": working?\n");
+  rtems_test_assert((call = dlsym (handle, "lib_func")) != NULL);
+  rtems_test_assert((call_ret = call ()) == 0);
+  rtems_test_assert(dlclose (handle) == 0);
+  printf ("handle: %p closed\n", handle);
+
+  return 0;
+}
diff --git a/testsuites/libtests/dl05/dl-load.h 
b/testsuites/libtests/dl05/dl-load.h
new file mode 100644
index 000..3f3910a
--- /dev/null
+++ b/testsuites/libtests/dl05/dl-load.h
@@ -0,0 +1,14 @@
+/*
+ * Copyright (c) 2014 Chris Johns .  All rights reserved.
+ *
+ * The license and distribution terms for this file may be
+ * found in the file LICENSE in this

[PATCH] libdl: The dl04 is too big for some BSPs. Do not built it.

2016-08-25 Thread Chris Johns 
---
 c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg  | 1 +
 c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg| 1 +
 c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg | 1 +
 3 files changed, 3 insertions(+)

diff --git a/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg 
b/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg
index 6b49cac..c83ab38 100644
--- a/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg
+++ b/c/src/lib/libbsp/arm/lm3s69xx/make/custom/lm3s3749-testsuite.tcfg
@@ -9,6 +9,7 @@ cdtest
 iostream
 dl01
 dl02
+dl04
 ftp01
 fileio
 flashdisk01
diff --git a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg 
b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg
index b914f24..5e7d350 100644
--- a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg
+++ b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc2362-testsuite.tcfg
@@ -8,6 +8,7 @@ capture
 cdtest
 dl01
 dl02
+dl04
 fileio
 flashdisk01
 fsdosfsname01
diff --git 
a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg 
b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
index 75a92f4..c28645b 100644
--- a/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
+++ b/c/src/lib/libbsp/arm/lpc24xx/make/custom/lpc23xx_tli800-testsuite.tcfg
@@ -10,6 +10,7 @@ complex
 crypt01
 dl01
 dl02
+dl04
 fileio
 flashdisk01
 fsdosfsformat01
-- 
2.4.6

___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel