Re: GCC 7.1 Released
On 2017-05-03 07:11, Sebastian Huber wrote: On 03/05/17 03:33, Chris Johns wrote: On 3/5/17 3:04 am, Joel Sherrill wrote: > >Thoughts on upgrading the 4.12 tools? > Looks good with updated dependent packages for gcc and with binutils-2.28. There are no build failures for just the tests. Attached is the warnings report which looks good if the networking warnings are ignored. I would rather use the GCC 6 which received some bug fix releases in the mean time and was used most of the time of the RTEMS 4.12 development. For RTEMS 5 I would use GCC 8. For the gaisler toolchain we are currently planning on using GCC 7.1. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: GCC 7.1 Released
On 09/05/17 14:54, Daniel Hellstrom wrote: On 2017-05-03 07:11, Sebastian Huber wrote: On 03/05/17 03:33, Chris Johns wrote: On 3/5/17 3:04 am, Joel Sherrill wrote: > >Thoughts on upgrading the 4.12 tools? > Looks good with updated dependent packages for gcc and with binutils-2.28. There are no build failures for just the tests. Attached is the warnings report which looks good if the networking warnings are ignored. I would rather use the GCC 6 which received some bug fix releases in the mean time and was used most of the time of the RTEMS 4.12 development. For RTEMS 5 I would use GCC 8. For the gaisler toolchain we are currently planning on using GCC 7.1. If you tested this version thoroughly than this is fine for me. Did you build all RTEMS targets which currently use GCC 6 with this version and can you provide the RSB patches? If yes, then please use the versions specified by GCC contrib/download_prerequisites for the support libraries. A new GCC version probably means new warnings to fix. We should manage the GCC selection better in the future. GCC 6 received considerable more testing and regression fixes than GCC 7.1 which is only two weeks old. -- 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: suggested changes and bug fixes for RTEMS
On Tue, May 9, 2017 at 12:16 PM, Pham, Phong wrote: > > > Hi RTEMS Maintainers, > > > > Pls. let me know which of these item # changes below (or delta within a > given item #) you do not wish to accommodate in the main line so that I will > provide it as part of my BSP. I am porting RTEMS to IBM PowerPC 750 chip; > very similar to MPC750 but there are minute differences. > > > > 1) Bug: In > rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index(). > See attachment irq-generic.c vs. irq-generic.c.orig > Please open a ticket on our Trac and attach a git-commit patch there or here, with "Close #." in the commit message. You can see the git-log for examples of how to format the commit message. > > > 2) Enhancement: Add support for IBM PowerPC 750 chip in > rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and > rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_categories.c > Should be fine. > > > 3) Bug: Missing a couple registers when DLAB is 1 in > rtems\c\src\libchip\serial\ns16550_p.h. Also add a #ifndef ASM around > libchip/serial.h inclusion. > Ditto on Trac. > > > 4) Suggestion: In pci.h, there are references to BSP_pci_configuration > data structure which is in pci.c. However, in this file, there are also > references to detect_host_bridge () in detect_raven_bridge.c. For folks > that are just interested in pci_read_config_dword() + its brothers, all they > need is to include pci.h and content for where BSP_pci_configuration is > defined. The rest of the stuff in pci.c should be separate. Or in another > word, data structures and #defines involving with BSP_pci_configuration > needs to be in separate files rather all stuffed in pci.c > Refactoring pci.c is acceptable. > > > 5) rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:triv121PgTblMap() > implementation only map virtual address to be the same as physical address > for a given address range (start + numPages). It also assume an increment > of page size for a given address range. I suggest that an argument of > triv121PgTblMap() is needed to specify the physical address to be mapped to > for a given range of addresses. Also another parameter is whether or not to > increment PhysAddr for each page. Enclosed in pte121.c is an implementation > of triv121PgTblMapPhysAddr() where a physical address is provided and it is > hard coded not to increase the physical address for a given address range. > So APIs are needed for these requests. Don’t know if and how much you want > to support me. If not, I’ll just add whatever you’re not supporting in my > BSP. > RTEMS does not have support for a non-identity mapping of virtual-physical memory. It is not clear that a non-identity mapping will work correctly, although I see no reason why it would not. You are welcome to suggest/implement improvements in this space. We have investigated some efforts to create BSP level memory management, see the ARM bsps for some ideas, and there are previous attempts to create APIs for memory management/protection, but nothing that has been mergeable. https://devel.rtems.org/wiki/Projects/MMU_Support > > > Thanks, > > Phong. > > > > PS: There are a couple more items but the first five should get things > rolling. > > Notice: This e-mail and any files transmitted with it may contain Data > Device Corporation's privileged and proprietary information. It is intended > solely for the use of the individual or entity to whom it is addressed. If > you are not the named recipient of this transmission, any disclosure, > copying, distribution or reliance on the contents of this message is > prohibited. If you received this e-mail in error, please destroy it and any > attached files and notify me immediately. > See if you can disable this notice for messages sent to the mailing list. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RE: suggested changes and bug fixes for RTEMS
Hi Gedare, My response is in ** * I don't quite know how to do a "attach a git-commit patch" nor where to get "Close #."... So I created tickets with code delta. Is this sufficient? Phong. -Original Message- From: ged...@gwmail.gwu.edu [mailto:ged...@gwmail.gwu.edu] On Behalf Of Gedare Bloom Sent: Tuesday, May 09, 2017 12:26 PM To: Pham, Phong Cc: devel@rtems.org Subject: Re: suggested changes and bug fixes for RTEMS On Tue, May 9, 2017 at 12:16 PM, Pham, Phong wrote: > > > Hi RTEMS Maintainers, > > > > Pls. let me know which of these item # changes below (or delta within > a given item #) you do not wish to accommodate in the main line so > that I will provide it as part of my BSP. I am porting RTEMS to IBM > PowerPC 750 chip; very similar to MPC750 but there are minute differences. > > > > 1) Bug: In > rtems\c\src\lib\libbsp\shared\src\irq-generic.c:bsp_interrupt_allocate_handler_index(). > See attachment irq-generic.c vs. irq-generic.c.orig > Please open a ticket on our Trac and attach a git-commit patch there or here, with "Close #." in the commit message. You can see the git-log for examples of how to format the commit message. ***Ticket #3014*** > > > 2) Enhancement: Add support for IBM PowerPC 750 chip in > rtems\c\src\lib\libcpu\powerpc\shared\include\cpuIdent.[c,h] and > rtems\c\src\lib\libcpu\powerpc\new-exceptions\bspsupport\ppc_exc_categ > ories.c > Should be fine. ***Ticket #3015*** > > > 3) Bug: Missing a couple registers when DLAB is 1 in > rtems\c\src\libchip\serial\ns16550_p.h. Also add a #ifndef ASM around > libchip/serial.h inclusion. > Ditto on Trac. ***Ticket #3016*** > > > 4) Suggestion: In pci.h, there are references to BSP_pci_configuration > data structure which is in pci.c. However, in this file, there are > also references to detect_host_bridge () in detect_raven_bridge.c. > For folks that are just interested in pci_read_config_dword() + its > brothers, all they need is to include pci.h and content for where > BSP_pci_configuration is defined. The rest of the stuff in pci.c > should be separate. Or in another word, data structures and #defines > involving with BSP_pci_configuration needs to be in separate files > rather all stuffed in pci.c > Refactoring pci.c is acceptable. ***Ticket #3017*** > > > 5) rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c:triv121PgTblMap() > implementation only map virtual address to be the same as physical > address for a given address range (start + numPages). It also assume > an increment of page size for a given address range. I suggest that > an argument of > triv121PgTblMap() is needed to specify the physical address to be > mapped to for a given range of addresses. Also another parameter is > whether or not to increment PhysAddr for each page. Enclosed in > pte121.c is an implementation of triv121PgTblMapPhysAddr() where a > physical address is provided and it is hard coded not to increase the > physical address for a given address range. > So APIs are needed for these requests. Don’t know if and how much you > want to support me. If not, I’ll just add whatever you’re not > supporting in my BSP. > RTEMS does not have support for a non-identity mapping of virtual-physical memory. It is not clear that a non-identity mapping will work correctly, although I see no reason why it would not. You are welcome to suggest/implement improvements in this space. We have investigated some efforts to create BSP level memory management, see the ARM bsps for some ideas, and there are previous attempts to create APIs for memory management/protection, but nothing that has been mergeable. https://devel.rtems.org/wiki/Projects/MMU_Support *** It looks like this is not something quick; so I will just take the file rtems\c\src\lib\libcpu\powerpc\mpc6xx\mmu\pte121.c and add it to our BSP to fit my need. *** Phong. > > > Thanks, > > Phong. > > > > PS: There are a couple more items but the first five should get things > rolling. > > Notice: This e-mail and any files transmitted with it may contain Data > Device Corporation's privileged and proprietary information. It is > intended solely for the use of the individual or entity to whom it is > addressed. If you are not the named recipient of this transmission, > any disclosure, copying, distribution or reliance on the contents of > this message is prohibited. If you received this e-mail in error, > please destroy it and any attached files and notify me immediately. > See if you can disable this notice for messages sent to the mailing list. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel Notice: This e-mail and any files transmitted with it may contain Data Device Corporation's privileged and proprietary information. It is intended solely for the use of the i
[PATCH 1/2] testsuites: Fix build dependences for generated files.
--- testsuites/libtests/dl01/Makefile.am | 2 ++ testsuites/libtests/dl02/Makefile.am | 2 ++ testsuites/libtests/dl04/Makefile.am | 2 ++ testsuites/libtests/dl05/Makefile.am | 2 ++ testsuites/libtests/tar01/Makefile.am | 4 testsuites/libtests/tar02/Makefile.am | 2 ++ 6 files changed, 14 insertions(+) diff --git a/testsuites/libtests/dl01/Makefile.am b/testsuites/libtests/dl01/Makefile.am index 07460694e2..653e38505f 100644 --- a/testsuites/libtests/dl01/Makefile.am +++ b/testsuites/libtests/dl01/Makefile.am @@ -14,6 +14,8 @@ AM_CPPFLAGS += -I$(top_srcdir)/../support/include LINK_OBJS = $(dl01_OBJECTS) LINK_LIBS = $(dl01_LDLIBS) +init.c: dl-tar.h + dl-o1.o: dl-o1.c dl.tar: dl-o1.o diff --git a/testsuites/libtests/dl02/Makefile.am b/testsuites/libtests/dl02/Makefile.am index 52ef98dc8a..12df8a0adf 100644 --- a/testsuites/libtests/dl02/Makefile.am +++ b/testsuites/libtests/dl02/Makefile.am @@ -14,6 +14,8 @@ AM_CPPFLAGS += -I$(top_srcdir)/../support/include LINK_OBJS = $(dl02_OBJECTS) LINK_LIBS = $(dl02_LDLIBS) +init.c: dl-tar.h + dl-o1.o: dl-o1.c dl-o2.o: dl-o2.c diff --git a/testsuites/libtests/dl04/Makefile.am b/testsuites/libtests/dl04/Makefile.am index a888434770..141dd5d500 100644 --- a/testsuites/libtests/dl04/Makefile.am +++ b/testsuites/libtests/dl04/Makefile.am @@ -15,6 +15,8 @@ AM_CPPFLAGS += -I$(top_srcdir)/../support/include LINK_OBJS = $(dl04_OBJECTS) LINK_LIBS = $(dl04_LDLIBS) +init.c: dl-tar.h + dl-o4.o: dl-o4.cpp dl.tar: dl-o4.o diff --git a/testsuites/libtests/dl05/Makefile.am b/testsuites/libtests/dl05/Makefile.am index 15608cd3c6..595d2748dd 100644 --- a/testsuites/libtests/dl05/Makefile.am +++ b/testsuites/libtests/dl05/Makefile.am @@ -14,6 +14,8 @@ AM_CPPFLAGS += -I$(top_srcdir)/../support/include LINK_OBJS = $(dl05_OBJECTS) LINK_LIBS = $(dl05_LDLIBS) +init.c: dl-tar.h + dl-o5.o: dl-o5.cpp dl.tar: dl-o5.o diff --git a/testsuites/libtests/tar01/Makefile.am b/testsuites/libtests/tar01/Makefile.am index d64d2c69df..201f1e83e1 100644 --- a/testsuites/libtests/tar01/Makefile.am +++ b/testsuites/libtests/tar01/Makefile.am @@ -48,6 +48,10 @@ tar01$(EXEEXT): $(tar01_OBJECTS) $(tar01_DEPENDENCIES) @rm -f tar01$(EXEEXT) $(make-exe) +init.c: initial_filesystem_tar.h \ + initial_filesystem_tar_gz.h \ + initial_filesystem_tar_xz.h + initial_filesystem_tar.c: initial_filesystem.tar $(BIN2C) -C initial_filesystem.tar initial_filesystem_tar CLEANFILES += initial_filesystem_tar.c diff --git a/testsuites/libtests/tar02/Makefile.am b/testsuites/libtests/tar02/Makefile.am index d04089b1b4..e83bfd2dd4 100644 --- a/testsuites/libtests/tar02/Makefile.am +++ b/testsuites/libtests/tar02/Makefile.am @@ -25,6 +25,8 @@ tar02$(EXEEXT): $(tar02_OBJECTS) $(tar02_DEPENDENCIES) @rm -f tar02$(EXEEXT) $(make-exe) +init.c: initial_filesystem_tar.h + initial_filesystem_tar.c: initial_filesystem.tar $(BIN2C) -C initial_filesystem.tar initial_filesystem_tar CLEANFILES += initial_filesystem_tar.c -- 2.12.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 2/2] testsuites: Build the tests in parallel is make is asked too.
---
testsuites/automake/subdirs.am | 51 --
1 file changed, 29 insertions(+), 22 deletions(-)
diff --git a/testsuites/automake/subdirs.am b/testsuites/automake/subdirs.am
index 63b1da1049..d03122c037 100644
--- a/testsuites/automake/subdirs.am
+++ b/testsuites/automake/subdirs.am
@@ -4,43 +4,50 @@
## It is a hack within many hacks and is designed to keep the source as clean
## as possible.
-all-local:
- @set fnord $(MAKEFLAGS); amf=$$2; \
- dot_seen=no; \
- target=`echo $@ | sed s/-recursive//`; \
- if test "$$target" = "all-local-am"; then \
+define TESTDIR
+.PHONY: $1
+$1:
+ @+set fnord $(MAKEFLAGS); \
+ subdir=$(1); \
+ target=`echo $(MAKECMDGOALS) | sed s/-recursive//`; \
+ if test "target" = "all-local-am"; then \
target="all-am"; \
fi; \
- if test "$$target" = "all-local"; then \
+ if test "target" = "all-local"; then \
target="all"; \
fi; \
tcheck="$(top_srcdir)/../../tools/build/rtems-test-check-py"; \
tdata="$(RTEMS_BSP)-testsuite.tcfg"; \
tincludes="$(top_srcdir)/../../c/src/lib/libbsp/$(RTEMS_CPU)/$(RTEMS_BSP_FAMILY)/make/custom:$(top_srcdir)/..";
\
- if test -f "$$tdata"; then \
+ if test -f "tdata"; then \
vtdata="$(RTEMS_CPU)/$(RTEMS_BSP_FAMILY)/make/custom/$(RTEMS_BSP)-testsuite.tcfg";
\
else \
vtdata="all tests"; \
fi; \
- echo "BSP Testsuite Data: $$vtdata"; \
- if test -f $$tcheck; then \
- list=`$$tcheck exclude $(RTEMS_BSP) $$tdata $$tincludes $(_SUBDIRS)`;
\
+ echo "BSP Testsuite Data: vtdata"; \
+ if test -f tcheck; then \
+ list=`tcheck exclude $(RTEMS_BSP) $$tdata tincludes
$(_SUBDIRS)`; \
else \
list=$(_SUBDIRS); \
fi; \
- for subdir in $$list; do \
- echo "Making $$target in $$subdir"; \
- if test "$$subdir" != "."; then \
- if test -f $$tcheck; then \
- test_FLAGS=`$$tcheck flags $(RTEMS_BSP) $$tdata $$tincludes
$$subdir`; \
+ if test "{list#*subdir}" != "{list}"; then \
+ echo "Making target in subdir"; \
+ if test "subdir" != "."; then \
+ if test -f tcheck; then \
+ test_FLAGS=`tcheck flags $(RTEMS_BSP) tdata tincludes
subdir`; \
fi; \
- local_target="$$target"; \
- if test -z "$$test_FLAGS"; then \
- echo "BSP Testsuite Flags: $$subdir: PASS"; \
+ local_target="target"; \
+ if test -z "test_FLAGS"; then \
+ echo "BSP Testsuite Flags: subdir: PASS"; \
else \
- echo "BSP Testsuite Flags: $$subdir: $$test_FLAGS"; \
+ echo "BSP Testsuite Flags: subdir: test_FLAGS"; \
fi; \
- (cd $$subdir && $(MAKE) $(AM_MAKEFLAGS) TEST_FLAGS="$$test_FLAGS"
$$local_target) \
-|| case "$$amf" in *=*) exit 1;; *k*) fail=yes;; *) exit 1;; esac;
\
+ cd subdir; \
+ $(MAKE) $(AM_MAKEFLAGS) TEST_FLAGS="test_FLAGS"
local_target; \
fi; \
- done; test -z "$$fail"
+ fi;
+endef
+
+$(foreach T,$(_SUBDIRS),$(eval $(call TESTDIR,$(strip $(T)
+
+all-local: $(_SUBDIRS)
--
2.12.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: suggested changes and bug fixes for RTEMS
Hello Phong, please have a look at https://devel.rtems.org/wiki/Developer/Contributing and https://devel.rtems.org/wiki/Developer/Git/Users -- 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
