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
Hi, On 09/16/2014 11:35 AM, Sebastian Huber 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? DanielH ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Cache Manager Functions with Processor Set
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. 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. I am in favour of removing these new API calls in case there is no strong use case. -- 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: Cache Manager Functions with Processor Set
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 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. In the optimization case you mention it wouldn't be that hard to use the platform specific alternative instead? 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 ___ 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
[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| 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 = 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 + * + *
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 > @@ -
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 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 >> $(I
[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 lic
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 =
Re: [PATCH] or1k: New cache manager.
Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill 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. > --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 >
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 > 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/or
Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill wrote: > > On 9/16/2014 12:54 PM, Hesham Moustafa wrote: >> Hi >> >> On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill >> 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 to continue, or q 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.
Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill wrote: > > On 9/16/2014 12:54 PM, Hesham Moustafa wrote: >> Hi >> >> On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill >> 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 +9
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 wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill 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 to continue, or q 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 file and see what file that was in, then that might help. + Have
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill wrote: > > > On 9/16/2014 1:34 PM, Hesham Moustafa wrote: >> >> On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill >> wrote: >>> >>> On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill 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 to continue, or q 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_
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 wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill wrote: On 9/16/2014 12:54 PM, Hesham Moustafa wrote: Hi On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill 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 to continue, or q 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. I did add just a function call t
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 to continue, or q 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 to continue, or q 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 to continue, or q 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 wrote: > On 9/16/2014 2:17 PM, Hesham Moustafa wrote: >> >> On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill >> wrote: >>> >>> >>> On 9/16/2014 1:34 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill wrote: > > On 9/16/2014 12:54 PM, Hesham Moustafa wrote: >> >> Hi >> >> On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill >> 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 i
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
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 to continue, or q 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
> to continue, or q 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
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 to continue, or q 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 > to continue, or q 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 to continue, or q 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 > wrote: >> On 9/16/2014 2:17 PM, Hesham Moustafa wrote: >>> On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill >>> wrote: On 9/16/2014 1:34 PM, Hesham Moustafa wrote: > On Tue, Sep 16, 2014 at 8:15 PM, Joel Sherrill > wrote: >> On 9/16/2014 12:54 PM, Hesham Moustafa wrote: >>> Hi >>> >>> On Tue, Sep 16, 2014 at 7:47 PM, Joel Sherrill >>> 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
Re: or1k test was .. Re: [PATCH] or1k: New cache manager.
On Tue, Sep 16, 2014 at 5:08 PM, Joel Sherrill 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 to continue, or q 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 >> to continue, or q 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 to continue, or q 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 >> wrote: >>> On 9/16/2014 2:17 PM, Hesham Moustafa wrote: On Tue, Sep 16, 2014 at 8:42 PM, Joel Sherrill wrote: > > On 9/16/2014 1:34 PM, He
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
[PATCH] redirector: Rename rtems_stdio_redirect_t
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.
---
cpukit/libmisc/redirector/stdio-redirect.c | 26 +-
cpukit/libmisc/redirector/stdio-redirect.h | 24
2 files changed, 25 insertions(+), 25 deletions(-)
diff --git a/cpukit/libmisc/redirector/stdio-redirect.c
b/cpukit/libmisc/redirector/stdio-redirect.c
index e6610cb..05a263d 100644
--- a/cpukit/libmisc/redirector/stdio-redirect.c
+++ b/cpukit/libmisc/redirector/stdio-redirect.c
@@ -31,7 +31,7 @@
#define RTEMS_STDIO_REDIRECT_FINISHED (1 << 1)
static bool
-rtems_stdio_redirect_lock(rtems_stdio_redirect_t* sr)
+rtems_stdio_redirect_lock(rtems_stdio_redirect* sr)
{
rtems_status_code sc = rtems_semaphore_obtain (sr->lock,
RTEMS_WAIT,
@@ -45,7 +45,7 @@ rtems_stdio_redirect_lock(rtems_stdio_redirect_t* sr)
}
static bool
-rtems_stdio_redirect_unlock(rtems_stdio_redirect_t* sr)
+rtems_stdio_redirect_unlock(rtems_stdio_redirect* sr)
{
rtems_status_code sc = rtems_semaphore_release (sr->lock);
if (sc != RTEMS_SUCCESSFUL)
@@ -57,7 +57,7 @@ rtems_stdio_redirect_unlock(rtems_stdio_redirect_t* sr)
}
static bool
-rtems_stdio_redirect_write (rtems_stdio_redirect_t* sr, const char* buf,
ssize_t len)
+rtems_stdio_redirect_write (rtems_stdio_redirect* sr, const char* buf, ssize_t
len)
{
if (!rtems_stdio_redirect_lock(sr))
return false;
@@ -99,7 +99,7 @@ rtems_stdio_redirect_write (rtems_stdio_redirect_t* sr, const
char* buf, ssize_t
static rtems_task
rtems_stdio_redirect_reader(rtems_task_argument arg)
{
- rtems_stdio_redirect_t* sr = (rtems_stdio_redirect_t*) arg;
+ rtems_stdio_redirect* sr = (rtems_stdio_redirect*) arg;
while (sr->state & RTEMS_STDIO_REDIRECT_RUNNING)
{
@@ -120,7 +120,7 @@ rtems_stdio_redirect_reader(rtems_task_argument arg)
rtems_task_delete(RTEMS_SELF);
}
-rtems_stdio_redirect_t*
+rtems_stdio_redirect*
rtems_stdio_redirect_open(int fd,
rtems_task_priority priority,
size_t stack_size,
@@ -129,11 +129,11 @@ rtems_stdio_redirect_open(int fd,
bool echo,
rtems_stdio_redirect_handler handler)
{
- rtems_stdio_redirect_t* sr;
- rtems_name name;
- rtems_status_code sc;
+ rtems_stdio_redirect* sr;
+ rtems_namename;
+ rtems_status_code sc;
- sr = malloc(sizeof(rtems_stdio_redirect_t));
+ sr = malloc(sizeof(*sr));
if (!sr)
{
fprintf(stderr, "error: stdio-redirect: no memory\n");
@@ -248,7 +248,7 @@ rtems_stdio_redirect_open(int fd,
}
void
-rtems_stdio_redirect_close(rtems_stdio_redirect_t* sr)
+rtems_stdio_redirect_close(rtems_stdio_redirect* sr)
{
if (rtems_stdio_redirect_lock(sr))
{
@@ -278,9 +278,9 @@ rtems_stdio_redirect_close(rtems_stdio_redirect_t* sr)
}
ssize_t
-rtems_stdio_redirect_read(rtems_stdio_redirect_t* sr,
- char* buffer,
- ssize_t length)
+rtems_stdio_redirect_read(rtems_stdio_redirect* sr,
+ char* buffer,
+ ssize_t length)
{
ssize_t written = 0;
diff --git a/cpukit/libmisc/redirector/stdio-redirect.h
b/cpukit/libmisc/redirector/stdio-redirect.h
index cf3d0cf..6f1d4cd 100644
--- a/cpukit/libmisc/redirector/stdio-redirect.h
+++ b/cpukit/libmisc/redirector/stdio-redirect.h
@@ -75,7 +75,7 @@ typedef struct
bool full;/**< The buffer is full. */
bool echo;/**< Echo the data out the
existing path. */
rtems_stdio_redirect_handler handler; /**< Redirected data handler. */
-} rtems_stdio_redirect_t;
+} rtems_stdio_redirect;
/*
* Open a redirector returning the handle to it.
@@ -83,18 +83,18 @@ typedef struct
* @param fd The file descriptor to redirect.
* @param priority The priority of the reader thread.
*/
-rtems_stdio_redirect_t* rtems_stdio_redirect_open(int
fd,
- rtems_task_priority
priority,
- size_t
stack_size,
- ssize_t
input_size,
- ssize_t
buffer_size,
- bool
echo,
- rtems_stdio_redirect_handler
handler);
+rtems_stdio_redirect* rtems_stdio_redirect_open(int
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
Re: [PATCH] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/2014 3:30 pm, Sebastian Huber wrote: 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. Will the linker complain if the symbols are in 2 separate archives ? To me this will appear confusing and result in questions about which is which and why there are 2 copies. I would like to see all these little libraries go away and in post 4.11 (say 5.0) I will be pushing for this very hard for this very reason. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Generalize _Cache_manager_Send_smp_msg()
Hello,
the function _Cache_manager_Send_smp_msg() is currently implemented in the BSP
specific domain and not available for all BSPs. This leads currently to build
errors. One hack to solve this problem exists:
http://lists.rtems.org/pipermail/devel/2014-September/007948.html
Since the functionality provided by _Cache_manager_Send_smp_msg() is useful for
other use cases (e.g. MMU maintenance operations) it should be generalized to
something like:
typedef struct SMP_Barrier_operation_node SMP_Barrier_operation_node;
typedef void ( *SMP_Barrier_operation )( SMP_Barrier_operation_node *node );
typedef struct {
Chain_Node Node;
SMP_Barrier_operation operation
cpu_set_t *recipients;
size_t setsize;
Atomic_Ulong done;
} SMP_Barrier_operation_node;
void _SMP_Barrier_operation( SMP_Barrier_operation_node *node );
Specializations can use something like:
typedef struct {
SMP_Barrier_operation_node Node;
some_type more_data;
} specialization_node;
Currently we have:
void
_Cache_manager_Send_smp_msg(
const size_t setsize,
const cpu_set_t *set,
Cache_manager_Function_ptr func,
const void * addr,
size_t size
)
{
uint32_t i;
Cache_manager_SMP_node node;
size_t set_size = CPU_ALLOC_SIZE( _SMP_Get_processor_count() );
char cpu_set_copy[set_size];
SMP_lock_Context lock_context;
if ( ! _System_state_Is_up( _System_state_Get() ) ) {
func( addr, size );
return;
}
[...]
So in the ! _System_state_Is_up( _System_state_Get() ) case there is no send.
This is not what a user expects from this function. One option is to add the
SMP message processing to the per-CPU state wait for change loop
(_Per_CPU_State_busy_wait()).
This can be used to avoid the special case _LEON3_Start_multitasking() function.
In case a processor not available to the application is set in the recipients,
then _Cache_manager_Send_smp_msg() waits forever. This function should ignore
unavailable processors. This is what the other processor set dependent
functions do (e.g. rtems_task_set_affinity()). There should be a test case for
this.
--
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] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/14 07:51, Chris Johns wrote:
On 17/09/2014 3:30 pm, Sebastian Huber wrote:
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.
Will the linker complain if the symbols are in 2 separate archives ?
Since the object files are identical it doesn't matter.
To me this will appear confusing and result in questions about which is which
and why there are 2 copies.
Yes, it is confusing and brittle, but it doesn't break user Makefiles.
Another option would be to patch GCC:
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index f14aed3..8f9fa1e 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -44,7 +44,7 @@ see the files COPYING3 and COPYING.RUNTIME respectively. If
not, see
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
"%{!nostdlib: %{qrtems: --start-group \
- -lrtemsbsp -lrtemscpu \
+ -lrtemsbsp -lrtemscpu -lz \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
#define TARGET_POSIX_IO
--
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] cpukit: Move zlib into librtemcpu.a and do not install libz.a.
On 17/09/2014 4:26 pm, Sebastian Huber wrote:
On 17/09/14 07:51, Chris Johns wrote:
On 17/09/2014 3:30 pm, Sebastian Huber wrote:
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.
Will the linker complain if the symbols are in 2 separate archives ?
Since the object files are identical it doesn't matter.
Hmm still ...
To me this will appear confusing and result in questions about which
is which
and why there are 2 copies.
Yes, it is confusing and brittle, but it doesn't break user Makefiles.
So a user's edit for a 4.11 release (ignoring the transition pain for
those with apps on 4.11) or us having to put up with the questions and
confusion for the life of 4.11.
Another option would be to patch GCC:
diff --git a/gcc/config/rtems.h b/gcc/config/rtems.h
index f14aed3..8f9fa1e 100644
--- a/gcc/config/rtems.h
+++ b/gcc/config/rtems.h
@@ -44,7 +44,7 @@ see the files COPYING3 and COPYING.RUNTIME
respectively. If not, see
#undef LIB_SPEC
#define LIB_SPEC "%{!qrtems: " STD_LIB_SPEC "} " \
"%{!nostdlib: %{qrtems: --start-group \
- -lrtemsbsp -lrtemscpu \
+ -lrtemsbsp -lrtemscpu -lz \
-lc -lgcc --end-group %{!qnolinkcmds: -T linkcmds%s}}}"
#define TARGET_POSIX_IO
Yeah this is ok.
Chris
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
