Re: [PATCH-V2] smptests/smpcache01: Remove invalidation of data cache lines from test
On 11/09/14 17:55, Daniel Cederman wrote: Invalidation of entire data cache might cause data written to the stack to get lost. --- testsuites/smptests/smpcache01/init.c | 47 +++ testsuites/smptests/smpcache01/smpcache01.doc | 1 - testsuites/smptests/smpcache01/smpcache01.scn | 18 -- 3 files changed, 33 insertions(+), 33 deletions(-) Thanks, I checked it in. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Cache Manager Functions with Processor Set
Hello, what is the use case for the following functions: rtems_cache_flush_multiple_data_lines_processor_set() rtems_cache_invalidate_multiple_data_lines_processor_set() rtems_cache_flush_entire_data_processor_set() rtems_cache_invalidate_entire_data_processor_set() ? Makes it sense on an SMP system running an operating system and application in one address space to do processor specific cache operations? The functions are currently unused (except for the test program). -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cache Manager Functions with Processor Set
On 09/16/2014 01:49 PM, Sebastian Huber wrote: On 16/09/14 13:42, Daniel Hellstrom wrote: Hello, what is the use case for the following functions: rtems_cache_flush_multiple_data_lines_processor_set() rtems_cache_invalidate_multiple_data_lines_processor_set() rtems_cache_flush_entire_data_processor_set() rtems_cache_invalidate_entire_data_processor_set() ? Makes it sense on an SMP system running an operating system and application in one address space to do processor specific cache operations? The functions are currently unused (except for the test program). I think most likely we want to flush/invalidate all CPUs in the system or only the local CPU's cache. Why do you ask, have you found a reason to limit/change the API? For all CPUs, you have the standard functions. You mean the standard function should operate on all CPUs? That would change the behaviour on SMP, but is probably what the user wants? You mean to add add cpu_local flush API next to the standard functions? The usage of local CPU is extremely dangerous since this makes only sense if you are absolutely sure that you stay on the current processor long enough. It might be dangerous, but we need that ability. Isn't it only to disable global interrupt and then it is safe, or when CPU affinity is used we could know that we're always executing on the same CPU? I am in favour of removing these new API calls in case there is no strong use case. What is the reason for that, footprint, ease BSP support etc? Daniel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cache Manager Functions with Processor Set
On 16/09/14 14:10, Daniel Hellstrom wrote: On 09/16/2014 01:49 PM, Sebastian Huber wrote: On 16/09/14 13:42, Daniel Hellstrom wrote: Hello, what is the use case for the following functions: rtems_cache_flush_multiple_data_lines_processor_set() rtems_cache_invalidate_multiple_data_lines_processor_set() rtems_cache_flush_entire_data_processor_set() rtems_cache_invalidate_entire_data_processor_set() ? Makes it sense on an SMP system running an operating system and application in one address space to do processor specific cache operations? The functions are currently unused (except for the test program). I think most likely we want to flush/invalidate all CPUs in the system or only the local CPU's cache. Why do you ask, have you found a reason to limit/change the API? For all CPUs, you have the standard functions. You mean the standard function should operate on all CPUs? That would change the behaviour on SMP, but is probably what the user wants? You mean to add add cpu_local flush API next to the standard functions? Yes, of course the standard functions should operate on all processors. We have symmetric multiprocessing. The cache operations on modern processors do this automatically. The usage of local CPU is extremely dangerous since this makes only sense if you are absolutely sure that you stay on the current processor long enough. It might be dangerous, but we need that ability. Isn't it only to disable global interrupt and then it is safe, or when CPU affinity is used we could know that we're always executing on the same CPU? Yes, but you must also guarantee that the data producer/consumer is also exactly this processor. Can you please give me an example, why you need this ability? For me this looks like an optimization for one particular special case on one particular hardware. I am in favour of removing these new API calls in case there is no strong use case. What is the reason for that, footprint, ease BSP support etc? We should not make it too hard for the users. I think it is too difficult to use these functions. They are also fairly non-standard. Which other operating system offers functions to do cache synchronization on a subset of processors? -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 5/6] or1k: New cache manager.
I pushed the rest but this (#5) does not apply cleanly. Please rebase your tree, make sure I merged the others ok, and recut the patch.. Thanks. --joel On 9/15/2014 5:33 PM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 14 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 339 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..cf6b8b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,12 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +# Cache +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel + +#libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c +#libbsp_a_SOURCES += ../../shared/include/cache_.h +#libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -86,6 +86,10 @@ $(PROJECT_INCLUDE)/bsp/tod.h: ../../shared/tod.h $(PROJECT_INCLUDE)/bsp/$(dirsta $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tod.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tod.h +$(PROJECT_INCLUDE)/bsp/cache_.h: ../shared/include/cache_.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) + $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/cache_.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/cache_.h + $(PROJECT_INCLUDE)/bsp/irq.h: include/irq.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/irq.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/irq.h diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg index 061f61a..ec73e3d 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg @@ -35,23 +35,23 @@ section mc end section ic - enabled = 0 + enabled = 1 nsets = 256 nways = 1 - blocksize = 16 + blocksize = 32 hitdelay = 20 - missdelay = 20 + missdelay = 60 end section dc - enabled = 0 - nsets = 256 + enabled = 1 + nsets = 256 nways = 1 - blocksize = 16 - load_hitdelay = 0 - load_missdelay = 0 - store_hitdelay = 0 - store_missdelay = 0 + blocksize = 32 + load_hitdelay = 40 + load_missdelay = 120 + store_hitdelay = 40 + store_missdelay = 120 end section pic @@ -78,6 +78,7 @@ section cpu ver = 0x12
Re: [PATCH] or1k: New cache manager.
I am not sure what it up. Chris committed a patch that changed the sort order to be more uniform. But your preinstall.am's don't match. Maybe you should try regenerating them. Perhaps they are from before his change being committed. $ git am /media/sf_jrs007/patches/\[PATCH\]\ or1k\ \ New\ cache\ manager..eml Applying: or1k: New cache manager. error: patch failed: c/src/lib/libbsp/or1k/or1ksim/preinstall.am:86 error: c/src/lib/libbsp/or1k/or1ksim/preinstall.am: patch does not apply error: patch failed: c/src/lib/libcpu/or1k/preinstall.am:22 error: c/src/lib/libcpu/or1k/preinstall.am: patch does not apply Patch failed at 0001 or1k: New cache manager. When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. On 9/16/2014 10:54 AM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 10 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 335 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..9c9b27c 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,8 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +# Cache +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -86,6 +86,10 @@ $(PROJECT_INCLUDE)/bsp/tod.h: ../../shared/tod.h $(PROJECT_INCLUDE)/bsp/$(dirsta $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tod.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tod.h +$(PROJECT_INCLUDE)/bsp/cache_.h: ../shared/include/cache_.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) + $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/cache_.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/cache_.h + $(PROJECT_INCLUDE)/bsp/irq.h: include/irq.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/irq.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/irq.h diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg index 061f61a..ec73e3d 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg @@ -35,23 +35,23 @@ section mc end section ic - enabled = 0 + enabled = 1 nsets
capture engine _States_Is_dormant check
I am converting the capture engine to remove capture tasks and use a combination of a special capture record and data moved to the tcb to replace it. I have a question on the rtems_capture_switch_task method where it is using a check for dormant state of the current task. I spoke with Joel on this and neither of us can see how this condition can occur. Does anyone have any insight this.I think this chunk can go away, but don't want to miss something. Thanks jennifer ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 5:59 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I am not sure what it up. Chris committed a patch that changed the sort order to be more uniform. But your preinstall.am's don't match. I generated an updated one in a separate commit before (after Chris change), and it's commited. Maybe you should try regenerating them. Perhaps they are from before his change being committed. I am sure this is after Chris change. I typed git reset --hard HEAD~N, then git pull, and finally applied my patches again and sent them out yesterday, and this is new version of the patch just generated now. running ./boostarp -p does not affect any preinstall.am (as it did before Chris change), so it's following latest order by Chris. I will submit another patch with a little modification to Makefile.am and consequently preinstall.am. It's against current RTEMS HEAD. $ git am /media/sf_jrs007/patches/\[PATCH\]\ or1k\ \ New\ cache\ manager..eml Applying: or1k: New cache manager. error: patch failed: c/src/lib/libbsp/or1k/or1ksim/preinstall.am:86 error: c/src/lib/libbsp/or1k/or1ksim/preinstall.am: patch does not apply error: patch failed: c/src/lib/libcpu/or1k/preinstall.am:22 error: c/src/lib/libcpu/or1k/preinstall.am: patch does not apply Patch failed at 0001 or1k: New cache manager. When you have resolved this problem run git am --resolved. If you would prefer to skip this patch, instead run git am --skip. To restore the original branch and stop patching run git am --abort. On 9/16/2014 10:54 AM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 10 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 335 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..9c9b27c 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,8 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +# Cache +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -86,6 +86,10 @@ $(PROJECT_INCLUDE)/bsp/tod.h: ../../shared/tod.h $(PROJECT_INCLUDE)/bsp/$(dirsta $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tod.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tod.h +$(PROJECT_INCLUDE)/bsp/cache_.h:
[PATCH] or1k: New cache manager.
Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 9 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 334 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..7e1c10b 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,7 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -86,6 +86,10 @@ $(PROJECT_INCLUDE)/bsp/tod.h: ../../shared/tod.h $(PROJECT_INCLUDE)/bsp/$(dirsta $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tod.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tod.h +$(PROJECT_INCLUDE)/bsp/cache_.h: ../shared/include/cache_.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) + $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/cache_.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/cache_.h + $(PROJECT_INCLUDE)/bsp/irq.h: include/irq.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/irq.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/irq.h diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg index 061f61a..ec73e3d 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg @@ -35,23 +35,23 @@ section mc end section ic - enabled = 0 + enabled = 1 nsets = 256 nways = 1 - blocksize = 16 + blocksize = 32 hitdelay = 20 - missdelay = 20 + missdelay = 60 end section dc - enabled = 0 - nsets = 256 + enabled = 1 + nsets = 256 nways = 1 - blocksize = 16 - load_hitdelay = 0 - load_missdelay = 0 - store_hitdelay = 0 - store_missdelay = 0 + blocksize = 32 + load_hitdelay = 40 + load_missdelay = 120 + store_hitdelay = 40 + store_missdelay = 120 end section pic @@ -78,6 +78,7 @@ section cpu ver = 0x12 cfg = 0x00 rev = 0x0001 + upr = 0x075f superscalar = 0 hazards = 0 dependstats = 0 diff --git a/c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c b/c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c new file mode 100644 index 000..d9fb7a7 --- /dev/null +++ b/c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c @@ -0,0 +1,25 @@ +/** + * @file + * + * @ingroup or1ksim + * + * @brief Benchmark timer support. + */ + +/* + * Copyright (c) 2014 by Hesham ALMatary + * + * The
Re: [PATCH] or1k: New cache manager.
I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. How about some new test results. :) --joel On 9/16/2014 12:30 PM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 9 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 334 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..7e1c10b 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,7 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am @@ -86,6 +86,10 @@ $(PROJECT_INCLUDE)/bsp/tod.h: ../../shared/tod.h $(PROJECT_INCLUDE)/bsp/$(dirsta $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/tod.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/tod.h +$(PROJECT_INCLUDE)/bsp/cache_.h: ../shared/include/cache_.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) + $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/cache_.h +PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/cache_.h + $(PROJECT_INCLUDE)/bsp/irq.h: include/irq.h $(PROJECT_INCLUDE)/bsp/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/bsp/irq.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/bsp/irq.h diff --git a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg index 061f61a..ec73e3d 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/sim.cfg +++ b/c/src/lib/libbsp/or1k/or1ksim/sim.cfg @@ -35,23 +35,23 @@ section mc end section ic - enabled = 0 + enabled = 1 nsets = 256 nways = 1 - blocksize = 16 + blocksize = 32 hitdelay = 20 - missdelay = 20 + missdelay = 60 end section dc - enabled = 0 - nsets = 256 + enabled = 1 + nsets = 256 nways = 1 - blocksize = 16 - load_hitdelay = 0 - load_missdelay = 0 - store_hitdelay = 0 - store_missdelay = 0 + blocksize = 32 + load_hitdelay = 40 + load_missdelay = 120 + store_hitdelay = 40 + store_missdelay = 120 end section pic @@ -78,6 +78,7 @@ section cpu ver = 0x12 cfg = 0x00 rev = 0x0001 + upr =
Re: [PATCH] or1k: New cache manager.
On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? + How far does ticker get? + Have you tried the trick I suggested earlier to disable the real clock tick driver, use the simulator idle tick code, and disable all the tests that are known to fail that way. This will eliminate the ISR code as an issue because you won't have any (if console output if polled). See h8sim for an example. Should be a Makefile.am change, adding an include to the testsuite configuration file, building and running. --joel On 9/16/2014 12:30 PM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 9 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 334 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..7e1c10b 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,7 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS += -I$(srcdir)/../../shared/include +libbsp_a_LIBADD += ../../../libcpu/@RTEMS_CPU@/shared/cache.rel ### # Special Rules # diff --git a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am index 1561b18..c0fa6b8 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/preinstall.am +++ b/c/src/lib/libbsp/or1k/or1ksim/preinstall.am
Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? The output of Hello World is: *** BEGIN OF TEST HELLO WORLD *** Hello World *** END OF TEST HELLO WORLD *** Fatal Error 5.0 Halted From GDB: Breakpoint 1, _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 39 _ISR_Disable_without_giant( level ); (gdb) bt #0 _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 #1 0x0003b5f8 in rtems_shutdown_executive (result=0) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/exshutdown.c:21 #2 0x0003b350 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:47 #3 0x0002cc30 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #4 0x2184 in Init (ignored=253816) at ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:33 ---Type return to continue, or q return to quit--- #5 0x0002c5b8 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #6 0x0002c540 in _User_extensions_Thread_exitted (executing=0x40080) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 + How far does ticker get? Ticker goes to the end: *** BEGIN OF TEST CLOCK TICK *** TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988 *** END OF TEST CLOCK TICK *** Fatal Error 9.276564 Halted From GDB: (gdb) break _Terminate Breakpoint 1 at 0x19a68: file ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line 39. (gdb) break _OR1K_Exception_default Breakpoint 2 at 0x2686c: file ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c, line 22. (gdb) c The program is not being run. (gdb) target remote :50001 Remote debugging using :50001 0x0100 in _reset () (gdb) c Continuing. Breakpoint 2, _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 22 rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame ); (gdb) bt #0 _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 #1 0x00026980 in jump_to_c_handler () Backtrace stopped: frame did not save the PC vector 6 is _unalign exception. + Have you tried the trick I suggested earlier to disable the real clock tick driver, use the simulator idle tick code, and disable all the tests that are known to fail that way. This will eliminate the ISR code as an issue because you won't have any (if console output if polled). See h8sim for an example. Should be a Makefile.am change, adding an include to the testsuite configuration file, building and running. --joel On
Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? + How far does ticker get? + Have you tried the trick I suggested earlier to disable the real clock tick driver, use the simulator idle tick code, and disable all the tests that are known to fail that way. This will eliminate the ISR code as an issue because you won't have any (if console output if polled). See h8sim for an example. Should be a Makefile.am change, adding an include to the testsuite configuration file, building and running. I added a definition in the clock driver to use fast clock idle before, but there is no program worked at all (console is polled). Should I add some files to Makefile.am instead of my clock, timer drivers. i.e, the following? # clock libbsp_a_SOURCES += ../../shared/clock_driver_simidle.c # console libbsp_a_SOURCES += ../../shared/console-polled.c # timer libbsp_a_SOURCES += ../../shared/timerstub.c --joel On 9/16/2014 12:30 PM, Hesham ALMatary wrote: Implement new cache functions for or1k and create new bspstart function for or1ksim to initialize instruction and data caches. Also, sim.cfg is modified to enable/confiure cache units. --- c/src/lib/libbsp/or1k/or1ksim/Makefile.am| 9 +- c/src/lib/libbsp/or1k/or1ksim/preinstall.am | 4 + c/src/lib/libbsp/or1k/or1ksim/sim.cfg| 21 +- c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c | 25 +++ c/src/lib/libbsp/or1k/shared/include/cache_.h| 43 c/src/lib/libcpu/or1k/Makefile.am| 3 +- c/src/lib/libcpu/or1k/preinstall.am | 4 + c/src/lib/libcpu/or1k/shared/cache/cache.c | 241 +++ c/src/lib/libcpu/or1k/shared/cache/cache_.h | 2 +- 9 files changed, 334 insertions(+), 18 deletions(-) create mode 100644 c/src/lib/libbsp/or1k/or1ksim/startup/bspstart.c create mode 100644 c/src/lib/libbsp/or1k/shared/include/cache_.h create mode 100644 c/src/lib/libcpu/or1k/shared/cache/cache.c diff --git a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am index 7af4fd0..7e1c10b 100644 --- a/c/src/lib/libbsp/or1k/or1ksim/Makefile.am +++ b/c/src/lib/libbsp/or1k/or1ksim/Makefile.am @@ -30,6 +30,7 @@ include_bsp_HEADERS += ../../shared/include/irq-info.h include_bsp_HEADERS += ../../shared/include/stackalloc.h include_bsp_HEADERS += ../../shared/include/uart-output-char.h include_bsp_HEADERS += ../../shared/tod.h +include_bsp_HEADERS += ../shared/include/cache_.h include_bsp_HEADERS += include/irq.h include_bsp_HEADERS += include/uart.h include_bsp_HEADERS += include/or1ksim.h @@ -61,8 +62,8 @@ libbsp_a_CPPFLAGS = libbsp_a_LIBADD = # Startup -libbsp_a_SOURCES += ../../shared/bspstart.c libbsp_a_SOURCES += ../../shared/bspreset.c +libbsp_a_SOURCES += startup/bspstart.c # Shared libbsp_a_SOURCES += ../../shared/bootcard.c @@ -72,8 +73,6 @@ libbsp_a_SOURCES += ../../shared/bsplibc.c libbsp_a_SOURCES += ../../shared/bsppost.c libbsp_a_SOURCES += ../../shared/bsppredriverhook.c libbsp_a_SOURCES += ../../shared/bsppretaskinghook.c -libbsp_a_SOURCES += ../../shared/cpucounterread.c -libbsp_a_SOURCES += ../../shared/cpucounterdiff.c libbsp_a_SOURCES += ../../shared/gnatinstallhandler.c libbsp_a_SOURCES += ../../shared/sbrk.c libbsp_a_SOURCES += ../../shared/src/stackalloc.c @@ -100,9 +99,7 @@ libbsp_a_SOURCES += ../../shared/src/irq-info.c libbsp_a_SOURCES += irq/irq.c # Cache -libbsp_a_SOURCES += ../../../libcpu/shared/src/cache_manager.c -libbsp_a_SOURCES += ../../shared/include/cache_.h -libbsp_a_CPPFLAGS +=
or1k test was .. Re: [PATCH] or1k: New cache manager.
On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? The output of Hello World is: *** BEGIN OF TEST HELLO WORLD *** Hello World *** END OF TEST HELLO WORLD *** Fatal Error 5.0 Halted From GDB: Breakpoint 1, _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 39 _ISR_Disable_without_giant( level ); (gdb) bt #0 _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 #1 0x0003b5f8 in rtems_shutdown_executive (result=0) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/exshutdown.c:21 #2 0x0003b350 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:47 #3 0x0002cc30 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #4 0x2184 in Init (ignored=253816) at ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:33 ---Type return to continue, or q return to quit--- #5 0x0002c5b8 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #6 0x0002c540 in _User_extensions_Thread_exitted (executing=0x40080) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 This is normal and OK. Look at the arguments to _Terminate. + How far does ticker get? Ticker goes to the end: *** BEGIN OF TEST CLOCK TICK *** TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988 *** END OF TEST CLOCK TICK *** Fatal Error 9.276564 Halted From GDB: (gdb) break _Terminate Breakpoint 1 at 0x19a68: file ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line 39. (gdb) break _OR1K_Exception_default Breakpoint 2 at 0x2686c: file ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c, line 22. (gdb) c The program is not being run. (gdb) target remote :50001 Remote debugging using :50001 0x0100 in _reset () (gdb) c Continuing. Breakpoint 2, _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 22 rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame ); (gdb) bt #0 _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 #1 0x00026980 in jump_to_c_handler () Backtrace stopped: frame did not save the PC vector 6 is _unalign exception. Set a break point at exit() (I think) and rtems_shutdown_executive(). You could start in the task which calls whatever kicks off the shutdown sequence. It looks like something in the shutdown procedure trips over something. This might be easy to debug. If the fault address is in the exception data, you can map that back to the nm
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? The output of Hello World is: *** BEGIN OF TEST HELLO WORLD *** Hello World *** END OF TEST HELLO WORLD *** Fatal Error 5.0 Halted From GDB: Breakpoint 1, _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 39 _ISR_Disable_without_giant( level ); (gdb) bt #0 _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 #1 0x0003b5f8 in rtems_shutdown_executive (result=0) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/exshutdown.c:21 #2 0x0003b350 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:47 #3 0x0002cc30 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #4 0x2184 in Init (ignored=253816) at ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:33 ---Type return to continue, or q return to quit--- #5 0x0002c5b8 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #6 0x0002c540 in _User_extensions_Thread_exitted (executing=0x40080) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 This is normal and OK. Look at the arguments to _Terminate. + How far does ticker get? Ticker goes to the end: *** BEGIN OF TEST CLOCK TICK *** TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988 *** END OF TEST CLOCK TICK *** Fatal Error 9.276564 Halted From GDB: (gdb) break _Terminate Breakpoint 1 at 0x19a68: file ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line 39. (gdb) break _OR1K_Exception_default Breakpoint 2 at 0x2686c: file ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c, line 22. (gdb) c The program is not being run. (gdb) target remote :50001 Remote debugging using :50001 0x0100 in _reset () (gdb) c Continuing. Breakpoint 2, _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 22 rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame ); (gdb) bt #0 _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 #1 0x00026980 in jump_to_c_handler () Backtrace stopped: frame did not save the PC vector 6 is _unalign exception. Set a break point at exit() (I think) and rtems_shutdown_executive(). You could start in the task which calls whatever kicks off the shutdown sequence. It
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
On 9/16/2014 2:17 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello world run and exit cleanly? The output of Hello World is: *** BEGIN OF TEST HELLO WORLD *** Hello World *** END OF TEST HELLO WORLD *** Fatal Error 5.0 Halted From GDB: Breakpoint 1, _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 39 _ISR_Disable_without_giant( level ); (gdb) bt #0 _Terminate ( the_source=RTEMS_FATAL_SOURCE_EXIT, is_internal=false, the_error=0) at ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c:39 #1 0x0003b5f8 in rtems_shutdown_executive (result=0) at ../../../../../../rtems/c/src/../../cpukit/sapi/src/exshutdown.c:21 #2 0x0003b350 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:47 #3 0x0002cc30 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #4 0x2184 in Init (ignored=253816) at ../../../../../../../rtems/c/src/../../testsuites/samples/hello/init.c:33 ---Type return to continue, or q return to quit--- #5 0x0002c5b8 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #6 0x0002c540 in _User_extensions_Thread_exitted (executing=0x40080) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 This is normal and OK. Look at the arguments to _Terminate. + How far does ticker get? Ticker goes to the end: *** BEGIN OF TEST CLOCK TICK *** TA1 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:00 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:05 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:10 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:15 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:20 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:25 12/31/1988 TA3 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA2 - rtems_clock_get_tod - 09:00:30 12/31/1988 TA1 - rtems_clock_get_tod - 09:00:30 12/31/1988 *** END OF TEST CLOCK TICK *** Fatal Error 9.276564 Halted From GDB: (gdb) break _Terminate Breakpoint 1 at 0x19a68: file ../../../../../../rtems/c/src/../../cpukit/score/src/interr.c, line 39. (gdb) break _OR1K_Exception_default Breakpoint 2 at 0x2686c: file ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c, line 22. (gdb) c The program is not being run. (gdb) target remote :50001 Remote debugging using :50001 0x0100 in _reset () (gdb) c Continuing. Breakpoint 2, _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 22 rtems_fatal( RTEMS_FATAL_SOURCE_EXCEPTION, (rtems_fatal_code) frame ); (gdb) bt #0 _OR1K_Exception_default (vector=6, frame=0x43854) at ../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-exception-default.c:22 #1 0x00026980 in jump_to_c_handler () Backtrace stopped: frame did not save the PC vector 6 is _unalign exception. Set a break point at exit() (I think) and rtems_shutdown_executive(). You could start in the task which calls whatever kicks off the shutdown sequence. It looks like something in the shutdown
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
Breakpoint 2, 0x0600 in _unalign () (gdb) bt #0 0x0600 in _unalign () #1 0x0002ec4c in _RBTree_Next ( node=0x40890, dir=RBT_RIGHT) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreenext.c:35 #2 0x0002e2f4 in _RBTree_Successor ( node=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:512 #3 0x0002e8c0 in _RBTree_Extract ( the_rbtree=0x4198c, the_node=0x40890) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreeextract.c:106 #4 0x00021524 in _RBTree_Get ( the_rbtree=0x4198c, dir=RBT_LEFT) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:540 #5 0x000215c8 in _Thread_queue_Dequeue (the_thread_queue=0x4198c) ---Type return to continue, or q return to quit--- at ../../../../../../rtems/c/src/../../cpukit/score/src/threadqdequeue.c:51 #6 0x00017c14 in _CORE_semaphore_Surrender (the_semaphore=0x4198c, id=436273153, api_semaphore_mp_support=0x0) at ../../../../../../rtems/c/src/../../cpukit/score/src/coresemsurrender.c:37 #7 0x00014868 in rtems_semaphore_release (id=436273153) at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semrelease.c:102 #8 0x00026cfc in rtems_libio_unlock () at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:253 #9 0x00026d5c in rtems_filesystem_default_unlock (mt_entry=0x49ce0) at ../../../../../../rtems/c/src/../../cpukit/libfs/src/defaults/default_loc---Type return to continue, or q return to quit--- k_and_unlock.c:39 #10 0x0002920c in rtems_filesystem_instance_unlock (loc=0x49c5c) at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:292 #11 0x00029268 in rtems_filesystem_location_free (loc=0x49c5c) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/freenode.c:29 #12 0x00029734 in rtems_libio_free ( iop=0x49c50) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio.c:136 #13 0x0002912c in close (fd=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/close.c:38 #14 0x64b0 in rtems_libio_exit () at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio_exit.c:31 ---Type return to continue, or q return to quit--- #15 0x0003b058 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:46 #16 0x00034798 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #17 0x2e3c in Test_task (unused=1) at ../../../../../../../rtems/c/src/../../testsuites/samples/ticker/tasks.c:41 #18 0x000340f0 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #19 0x00034078 in _User_extensions_Thread_exitted (executing=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 Backtrace stopped: frame did not save the PC (gdb) It breaks at _RBTree_Next specifically at the following line: while ( ( current = current-child[ opp_dir ] ) != NULL ) (gdb) p current-child[ opp_dir ] Cannot access memory at address 0xa010006 (gdb) p current $1 = (RBTree_Node *) 0xa010002 This address is invalid, the current memory length should be only 32 MB (0x200) http://git.rtems.org/rtems/tree/c/src/lib/libbsp/or1k/or1ksim/startup/linkcmds#n20 So I guest current-child is overwritten somehow? On Tue, Sep 16, 2014 at 9:21 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 2:17 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself and folded that into the rest of your patch. It should all be committed now. Thanks for doing this, me too do not know what's wrong. BTW, commits are not mirrored on github since 4 days ago. How about some new test results. :) I did run one last night, no big progress since previous results :( Is there any tool, script, utility program or whatever that I can use to detect wrong memory access (i.e, stack overwrite, heap corruption, access to another task context)? I tried to add -fstack-protector-all to gcc, but QEMU did not get anything or core-dump, ticker just hangs. I haven't checked into how gcc does its stack overwrite protection. The tests by themselves don't have these problems. The first possible source is incorrect layout of sections to memory by the linker script. There is some debug code in boot There used to be debug printk's in bspgetworkarea.c so you could check if areas overlapped. That usually causes bad issues though. Let's go through some basics: + Does hello
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
Breakpoint 1, _RBTree_Next (node=0x40890, dir=RBT_RIGHT)
at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreenext.c:35
35 RBTree_Direction opp_dir = _RBTree_Opposite_direction( dir );
(gdb) n
36 RBTree_Node *current = node-child[ dir ];
(gdb) n
37 RBTree_Node *next = NULL;
(gdb) p/x current
$1 = 0xa010002
(gdb) p/x node-child
$2 = {0x3d254, 0xa010002}
(gdb) p dir
$3 = RBT_RIGHT
(gdb) p/x node-child
$4 = 0x40894
(gdb) i r
r0 0x0 0
r1 0x439a8 0x439a8
r2 0x439c8 0x439c8
r1 = sp
r2 = fp
(gdb) b _CPU_Context_Initialize
Breakpoint 1 at 0x2f648: file
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-context-initialize.c,
line 33.
(gdb) c
Continuing.
Breakpoint 1, _CPU_Context_Initialize (context=0x3fe28,
stack_area_begin=0x41c10, stack_area_size=4096, new_level=0,
entry_point=0x34078 _Thread_Handler,
is_fp=false, tls_area=0x0) at
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-context-initialize.c:33
33 uint32_t stack = ((uint32_t) stack_area_begin) - 200;
(gdb) c
Continuing.
Breakpoint 1, _CPU_Context_Initialize (context=0x403e0,
stack_area_begin=0x42c18, stack_area_size=4096, new_level=0,
entry_point=0x34078 _Thread_Handler,
is_fp=false, tls_area=0x0) at
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-context-initialize.c:33
33 uint32_t stack = ((uint32_t) stack_area_begin) - 200;
(gdb) c
Continuing.
Breakpoint 1, _CPU_Context_Initialize (context=0x40970,
stack_area_begin=0x43c20, stack_area_size=8192, new_level=0,
entry_point=0x34078 _Thread_Handler,
is_fp=false, tls_area=0x0) at
../../../../../../../../rtems/c/src/../../cpukit/score/cpu/or1k/or1k-context-initialize.c:33
33 uint32_t stack = ((uint32_t) stack_area_begin) - 200;
(gdb) p/x bsp_section_work_end
$5 = 0x200
(gdb) p/x bsp_section_work_size
$6 = 0x1fc13c0
(gdb) p/x bsp_section_work_begin
$7 = 0x3ec40
The corresponding linkcmds.base part is:
.work : ALIGN_WITH_INPUT {
/*
* The work section will occupy the remaining REGION_WORK region and
* contains the RTEMS work space and heap.
*/
bsp_section_work_begin = .;
. += ORIGIN (REGION_WORK) + LENGTH (REGION_WORK) - ABSOLUTE (.);
bsp_section_work_end = .;
} REGION_WORK AT REGION_WORK
bsp_section_work_size = bsp_section_work_end - bsp_section_work_begin;
.stack : ALIGN_WITH_INPUT {
bsp_section_stack_end = .;
} REGION_STACK AT REGION_STACK
bsp_section_stack_size = bsp_section_stack_begin - bsp_section_stack_end;
RamBase = ORIGIN (REGION_WORK);
RamSize = LENGTH (REGION_WORK);
WorkAreaBase = bsp_section_work_begin;
HeapSize = 0;
}
On Tue, Sep 16, 2014 at 9:45 PM, Hesham Moustafa
heshamelmat...@gmail.com wrote:
Breakpoint 2, 0x0600 in _unalign ()
(gdb) bt
#0 0x0600 in _unalign ()
#1 0x0002ec4c in _RBTree_Next (
node=0x40890, dir=RBT_RIGHT)
at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreenext.c:35
#2 0x0002e2f4 in _RBTree_Successor (
node=0x40890)
at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:512
#3 0x0002e8c0 in _RBTree_Extract (
the_rbtree=0x4198c,
the_node=0x40890)
at
../../../../../../rtems/c/src/../../cpukit/score/src/rbtreeextract.c:106
#4 0x00021524 in _RBTree_Get (
the_rbtree=0x4198c, dir=RBT_LEFT)
at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:540
#5 0x000215c8 in _Thread_queue_Dequeue
(the_thread_queue=0x4198c)
---Type return to continue, or q return to quit---
at
../../../../../../rtems/c/src/../../cpukit/score/src/threadqdequeue.c:51
#6 0x00017c14 in _CORE_semaphore_Surrender (the_semaphore=0x4198c,
id=436273153,
api_semaphore_mp_support=0x0)
at
../../../../../../rtems/c/src/../../cpukit/score/src/coresemsurrender.c:37
#7 0x00014868 in rtems_semaphore_release (id=436273153)
at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semrelease.c:102
#8 0x00026cfc in rtems_libio_unlock ()
at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:253
#9 0x00026d5c in rtems_filesystem_default_unlock (mt_entry=0x49ce0)
at
../../../../../../rtems/c/src/../../cpukit/libfs/src/defaults/default_loc---Type
return to continue, or q return to quit---
k_and_unlock.c:39
#10 0x0002920c in rtems_filesystem_instance_unlock (loc=0x49c5c)
at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:292
#11 0x00029268 in rtems_filesystem_location_free (loc=0x49c5c)
at
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/freenode.c:29
#12 0x00029734 in rtems_libio_free (
iop=0x49c50)
at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio.c:136
#13 0x0002912c in close (fd=0)
at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/close.c:38
#14 0x64b0 in rtems_libio_exit ()
at
../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio_exit.c:31
---Type return to
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
Gedare.. cc'ed you for help in spotting an empty rbtree in gdb. See below. On 9/16/2014 2:45 PM, Hesham Moustafa wrote: Breakpoint 2, 0x0600 in _unalign () (gdb) bt #0 0x0600 in _unalign () #1 0x0002ec4c in _RBTree_Next ( node=0x40890, dir=RBT_RIGHT) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreenext.c:35 #2 0x0002e2f4 in _RBTree_Successor ( node=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:512 #3 0x0002e8c0 in _RBTree_Extract ( the_rbtree=0x4198c, the_node=0x40890) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreeextract.c:106 #4 0x00021524 in _RBTree_Get ( the_rbtree=0x4198c, dir=RBT_LEFT) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:540 #5 0x000215c8 in _Thread_queue_Dequeue (the_thread_queue=0x4198c) ---Type return to continue, or q return to quit--- at ../../../../../../rtems/c/src/../../cpukit/score/src/threadqdequeue.c:51 #6 0x00017c14 in _CORE_semaphore_Surrender (the_semaphore=0x4198c, id=436273153, api_semaphore_mp_support=0x0) at ../../../../../../rtems/c/src/../../cpukit/score/src/coresemsurrender.c:37 #7 0x00014868 in rtems_semaphore_release (id=436273153) at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semrelease.c:102 #8 0x00026cfc in rtems_libio_unlock () at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:253 #9 0x00026d5c in rtems_filesystem_default_unlock (mt_entry=0x49ce0) at ../../../../../../rtems/c/src/../../cpukit/libfs/src/defaults/default_loc---Type return to continue, or q return to quit--- k_and_unlock.c:39 #10 0x0002920c in rtems_filesystem_instance_unlock (loc=0x49c5c) at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:292 #11 0x00029268 in rtems_filesystem_location_free (loc=0x49c5c) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/freenode.c:29 #12 0x00029734 in rtems_libio_free ( iop=0x49c50) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio.c:136 #13 0x0002912c in close (fd=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/close.c:38 #14 0x64b0 in rtems_libio_exit () at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio_exit.c:31 ---Type return to continue, or q return to quit--- #15 0x0003b058 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:46 #16 0x00034798 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #17 0x2e3c in Test_task (unused=1) at ../../../../../../../rtems/c/src/../../testsuites/samples/ticker/tasks.c:41 #18 0x000340f0 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #19 0x00034078 in _User_extensions_Thread_exitted (executing=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 Backtrace stopped: frame did not save the PC (gdb) It breaks at _RBTree_Next specifically at the following line: while ( ( current = current-child[ opp_dir ] ) != NULL ) (gdb) p current-child[ opp_dir ] Cannot access memory at address 0xa010006 (gdb) p current $1 = (RBTree_Node *) 0xa010002 These look like object ids. This address is invalid, the current memory length should be only 32 MB (0x200) http://git.rtems.org/rtems/tree/c/src/lib/libbsp/or1k/or1ksim/startup/linkcmds#n20 So I guest current-child is overwritten somehow? Yep. Two approaches. + Set a watchpoint in gdb if it is supported. But even if supported, it will likely slow the run tremendously. + Break selectively and more or less binary search for where it is overwritten. I would break at the first call to _ISR_Dispatch (or whatever you called it) and see if it gets clobbered. That could be clobbered VERY early in the program. It could be a blown stack. But it could just be a stray write. Check the value of that semaphore's rbtree when you get to Init and just break periodically and see where it is corrupt. I cc'ed Gedare because I don't know how to spot that the rbtree is empty in gdb. You need to see where that memory is overwritten. Again running all tests with the simulator clock tick could eliminate the ISR code as the culprit. :) On Tue, Sep 16, 2014 at 9:21 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 2:17 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: I don't understand this but I got it applied. I manually edited the saved email to delete the preinstall.am changes. I committed the rest. Then I ran bootstrap -p myself
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 5:08 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: Gedare.. cc'ed you for help in spotting an empty rbtree in gdb. See below. On 9/16/2014 2:45 PM, Hesham Moustafa wrote: Breakpoint 2, 0x0600 in _unalign () (gdb) bt #0 0x0600 in _unalign () #1 0x0002ec4c in _RBTree_Next ( node=0x40890, dir=RBT_RIGHT) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreenext.c:35 #2 0x0002e2f4 in _RBTree_Successor ( node=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:512 #3 0x0002e8c0 in _RBTree_Extract ( the_rbtree=0x4198c, the_node=0x40890) at ../../../../../../rtems/c/src/../../cpukit/score/src/rbtreeextract.c:106 #4 0x00021524 in _RBTree_Get ( the_rbtree=0x4198c, dir=RBT_LEFT) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/rbtree.h:540 #5 0x000215c8 in _Thread_queue_Dequeue (the_thread_queue=0x4198c) ---Type return to continue, or q return to quit--- at ../../../../../../rtems/c/src/../../cpukit/score/src/threadqdequeue.c:51 #6 0x00017c14 in _CORE_semaphore_Surrender (the_semaphore=0x4198c, id=436273153, api_semaphore_mp_support=0x0) at ../../../../../../rtems/c/src/../../cpukit/score/src/coresemsurrender.c:37 #7 0x00014868 in rtems_semaphore_release (id=436273153) at ../../../../../../rtems/c/src/../../cpukit/rtems/src/semrelease.c:102 #8 0x00026cfc in rtems_libio_unlock () at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:253 #9 0x00026d5c in rtems_filesystem_default_unlock (mt_entry=0x49ce0) at ../../../../../../rtems/c/src/../../cpukit/libfs/src/defaults/default_loc---Type return to continue, or q return to quit--- k_and_unlock.c:39 #10 0x0002920c in rtems_filesystem_instance_unlock (loc=0x49c5c) at ../../cpukit/../../../or1ksim/lib/include/rtems/libio_.h:292 #11 0x00029268 in rtems_filesystem_location_free (loc=0x49c5c) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/freenode.c:29 #12 0x00029734 in rtems_libio_free ( iop=0x49c50) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio.c:136 #13 0x0002912c in close (fd=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/close.c:38 #14 0x64b0 in rtems_libio_exit () at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/libio_exit.c:31 ---Type return to continue, or q return to quit--- #15 0x0003b058 in _exit (status=0) at ../../../../../../rtems/c/src/../../cpukit/libcsupport/src/newlibc_exit.c:46 #16 0x00034798 in exit (code=0) at ../../../../../gcc-4.8.3/newlib/libc/stdlib/exit.c:70 #17 0x2e3c in Test_task (unused=1) at ../../../../../../../rtems/c/src/../../testsuites/samples/ticker/tasks.c:41 #18 0x000340f0 in _Thread_Handler () at ../../../../../../rtems/c/src/../../cpukit/score/src/threadhandler.c:192 #19 0x00034078 in _User_extensions_Thread_exitted (executing=0x40890) at ../../cpukit/../../../or1ksim/lib/include/rtems/score/userextimpl.h:243 Backtrace stopped: frame did not save the PC (gdb) It breaks at _RBTree_Next specifically at the following line: while ( ( current = current-child[ opp_dir ] ) != NULL ) (gdb) p current-child[ opp_dir ] Cannot access memory at address 0xa010006 (gdb) p current $1 = (RBTree_Node *) 0xa010002 These look like object ids. This address is invalid, the current memory length should be only 32 MB (0x200) http://git.rtems.org/rtems/tree/c/src/lib/libbsp/or1k/or1ksim/startup/linkcmds#n20 So I guest current-child is overwritten somehow? Yep. Two approaches. + Set a watchpoint in gdb if it is supported. But even if supported, it will likely slow the run tremendously. + Break selectively and more or less binary search for where it is overwritten. I would break at the first call to _ISR_Dispatch (or whatever you called it) and see if it gets clobbered. That could be clobbered VERY early in the program. It could be a blown stack. But it could just be a stray write. Check the value of that semaphore's rbtree when you get to Init and just break periodically and see where it is corrupt. I cc'ed Gedare because I don't know how to spot that the rbtree is empty in gdb. You should be able to watch one of the pointers from the rbtree_control. I think there is a check for rbtree_is_empty that would also tell you what to do. I don't have the code in front of me to check. -Gedare You need to see where that memory is overwritten. Again running all tests with the simulator clock tick could eliminate the ISR code as the culprit. :) On Tue, Sep 16, 2014 at 9:21 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 2:17 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill joel.sherr...@oarcorp.com wrote:
Re: capture engine _States_Is_dormant check
On 17/09/2014 3:22 am, Jennifer Averett wrote: I am converting the capture engine to remove capture tasks and use a combination of a special capture record and data moved to the tcb to replace it. I have a question on the rtems_capture_switch_task method where it is using a check for dormant state of the current task. I spoke with Joel on this and neither of us can see how this condition can occur. Does anyone have any insight this.I think this chunk can go away, but don’t want to miss something. I cannot see a reason for this code any more. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: capture engine _States_Is_dormant check
On 9/16/2014 4:28 PM, Chris Johns wrote: On 17/09/2014 3:22 am, Jennifer Averett wrote: I am converting the capture engine to remove capture tasks and use a combination of a special capture record and data moved to the tcb to replace it. I have a question on the rtems_capture_switch_task method where it is using a check for dormant state of the current task. I spoke with Joel on this and neither of us can see how this condition can occur. Does anyone have any insight this.I think this chunk can go away, but don’t want to miss something. I cannot see a reason for this code any more. Thanks. I couldn't remember there every being a reason for it but getting a second vote is appreciated. :) Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- Joel Sherrill, Ph.D. Director of Research Development joel.sherr...@oarcorp.comOn-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available(256) 722-9985 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. --- cpukit/wrapup/Makefile.am | 2 ++ cpukit/zlib/Makefile.am | 2 +- cpukit/zlib/preinstall.am | 14 -- 3 files changed, 3 insertions(+), 15 deletions(-) diff --git a/cpukit/wrapup/Makefile.am b/cpukit/wrapup/Makefile.am index e89426f..b8c0ee2 100644 --- a/cpukit/wrapup/Makefile.am +++ b/cpukit/wrapup/Makefile.am @@ -77,6 +77,8 @@ if NEWLIB TMP_LIBS += ../libmd/libmd.a endif +TMP_LIBS += ../zlib/libz.a + librtemscpu.a: $(TMP_LIBS) rm -f $@ $(MKDIR_P) $(ARCH) diff --git a/cpukit/zlib/Makefile.am b/cpukit/zlib/Makefile.am index 478134b..54be345 100644 --- a/cpukit/zlib/Makefile.am +++ b/cpukit/zlib/Makefile.am @@ -1,6 +1,6 @@ include $(top_srcdir)/automake/compile.am -project_lib_LIBRARIES = libz.a +noinst_LIBRARIES = libz.a libz_a_SOURCES = adler32.c libz_a_SOURCES += compress.c diff --git a/cpukit/zlib/preinstall.am b/cpukit/zlib/preinstall.am index 7eb8f7b..a17f25c 100644 --- a/cpukit/zlib/preinstall.am +++ b/cpukit/zlib/preinstall.am @@ -13,25 +13,11 @@ all-am: $(PREINSTALL_FILES) PREINSTALL_FILES = CLEANFILES += $(PREINSTALL_FILES) -all-local: $(TMPINSTALL_FILES) - -TMPINSTALL_FILES = -CLEANFILES += $(TMPINSTALL_FILES) - -$(PROJECT_LIB)/$(dirstamp): - @$(MKDIR_P) $(PROJECT_LIB) - @: $(PROJECT_LIB)/$(dirstamp) -PREINSTALL_DIRS += $(PROJECT_LIB)/$(dirstamp) - $(PROJECT_INCLUDE)/$(dirstamp): @$(MKDIR_P) $(PROJECT_INCLUDE) @: $(PROJECT_INCLUDE)/$(dirstamp) PREINSTALL_DIRS += $(PROJECT_INCLUDE)/$(dirstamp) -$(PROJECT_LIB)/libz.a: libz.a $(PROJECT_LIB)/$(dirstamp) - $(INSTALL_DATA) $ $(PROJECT_LIB)/libz.a -TMPINSTALL_FILES += $(PROJECT_LIB)/libz.a - $(PROJECT_INCLUDE)/zlib.h: zlib.h $(PROJECT_INCLUDE)/$(dirstamp) $(INSTALL_DATA) $ $(PROJECT_INCLUDE)/zlib.h PREINSTALL_FILES += $(PROJECT_INCLUDE)/zlib.h -- 1.8.5.2 (Apple Git-48) ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] redirector: Rename rtems_stdio_redirect_t
On 17/09/2014 3:24 pm, Sebastian Huber wrote: Rename rtems_stdio_redirect_t to rtems_stdio_redirect since the namespace *_t is reserved by POSIX, see also The Open Group Base Specifications Issue 6 IEEE Std 1003.1, 2004 Edition, 2.2.2 The Name Space. Thanks. Please commit. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/14 02:26, Chris Johns wrote: The JFFS2 file system can optionally use zlib as a compressor and if this is the only reference to zlib the application will not link. Adding -lz does not work because librtemscpu.a is added to the end of ld's command line via the bsp_specs hack and user added libraries appear before this. If we remove libz.a then this will break all application Makefiles, that assume that RTEMS provides it. I would still provide libz.a. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cache Manager Functions with Processor Set
On 16/09/14 16:00, Daniel Hellstrom wrote: On 09/16/2014 02:23 PM, Sebastian Huber wrote: On 16/09/14 14:10, Daniel Hellstrom wrote: On 09/16/2014 01:49 PM, Sebastian Huber wrote: On 16/09/14 13:42, Daniel Hellstrom wrote: Hello, what is the use case for the following functions: rtems_cache_flush_multiple_data_lines_processor_set() rtems_cache_invalidate_multiple_data_lines_processor_set() rtems_cache_flush_entire_data_processor_set() rtems_cache_invalidate_entire_data_processor_set() ? Makes it sense on an SMP system running an operating system and application in one address space to do processor specific cache operations? The functions are currently unused (except for the test program). I think most likely we want to flush/invalidate all CPUs in the system or only the local CPU's cache. Why do you ask, have you found a reason to limit/change the API? For all CPUs, you have the standard functions. You mean the standard function should operate on all CPUs? That would change the behaviour on SMP, but is probably what the user wants? You mean to add add cpu_local flush API next to the standard functions? Yes, of course the standard functions should operate on all processors. We have symmetric multiprocessing. The cache operations on modern processors do this automatically. That sounds better. When you say modern processors do that automatically, do you mean even for L2 and L3 caches? The higher level caches are usually inclusive unified caches, so yes unless you want to make it painful for the user. The usage of local CPU is extremely dangerous since this makes only sense if you are absolutely sure that you stay on the current processor long enough. It might be dangerous, but we need that ability. Isn't it only to disable global interrupt and then it is safe, or when CPU affinity is used we could know that we're always executing on the same CPU? Yes, but you must also guarantee that the data producer/consumer is also exactly this processor. Can you please give me an example, why you need this ability? For me this looks like an optimization for one particular special case on one particular hardware. Is it common for SMP operating systems not to have the ability to flush/invalidate its local CPU? DMA is one reason. I think your emphasis on local CPUs is artificial. The concept of SMP is to share data with low overhead on multiple processors. In the optimization case you mention it wouldn't be that hard to use the platform specific alternative instead? Yes, I would prefer to use platform specific functions to do such a non-portable stuff that is pretty easy to get wrong. I am in favour of removing these new API calls in case there is no strong use case. What is the reason for that, footprint, ease BSP support etc? We should not make it too hard for the users. I think it is too difficult to use these functions. They are also fairly non-standard. Which other operating system offers functions to do cache synchronization on a subset of processors? I can't see any particular use case for doing these operation on a set of CPUs. One or all CPUs is what I see. If you want to remove them its fine by me, what I'm trying to say I guess is that it doesn't cost that much to have them around. Since they depend on the local-cpu cache operations anyway, and we still need the IPI handler for the all-cpu operations. Daniel I am perfectly fine with the _Cache_manager_Send_smp_msg() method in general. I have a problem with exposing this complicated processor set specific cache functions to users via rtems_cache_*() functions. It a lot safer to simply do a global flush/invalidate. -- Sebastian Huber, embedded brains GmbH Address : Dornierstr. 4, D-82178 Puchheim, Germany Phone : +49 89 189 47 41-16 Fax : +49 89 189 47 41-09 E-Mail : sebastian.hu...@embedded-brains.de PGP : Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
