waf: Post-process object file
Hello, for the libbsd we have the problem that we expose a lot of symbols from the FreeBSD kernel space to the applications. There are several known conflicts, e.g. FreeBSD log() vs. standard math library log(). The current approach to solve this issue is to generate a file with lots of #define xx _bsd_xx ... defines to rename at C pre-processor level. This is however quite brittle and doesn't work in general. An alternative would be to post-process the kernel-space object files with something like this objcopy --redefine-syms redefines.txt x.o with a redefines.txt xx=_bsd_xx ... My question is now: how can I add this post-processing step to the waf based libbsd build system? -- 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] Add RTEMS 4.12 build set
On 08/11/15 01:05, Chris Johns wrote: Are there any architecture regressions with gcc-6? m32c, moxie, v850 don't work with GCC 6. epiphany and or1k still use non-FSF GCC. What archs have to actually run? arm, powerpc, sparc. I am happy to move to gcc-6 for archs we know are working. For those that do not I am not so sure we should move them. The broken targets use the 4.11 configuration. -- 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: TMS570 BSP updates and LwIP support
On Mon, Nov 9, 2015 at 8:30 PM, Pavel Pisa wrote: > Hello Martin, >> + TMS570_POM.GLBCTRL = 0 | (TMS570_POM_GLBCTRL_OTADDR(~0) & >> +pom_global_overlay_target_address_start); >> >> I don't see the point of doing (0 | something). > > This is to highlight that register value is not only the base > of overlay target address. The following expression > contains all information based on our headers using > RTEMS standard for fields values. > > TMS570_POM.GLBCTRL = TMS570_POM_GLBCTRL_ON_OFF(0) | >TMS570_POM_GLBCTRL_ETO(0) | >(TMS570_POM_GLBCTRL_OTADDR(~0) & > pom_global_overlay_target_address_start); > > It has same value and effect as simplified one. > But if you prefer this form then I change code. I'd rather do TMS570_POM.GLBCTRL = (TMS570_POM_GLBCTRL_OTADDR(~0) & pom_global_overlay_target_address_start); but that's just me. >> In any case, is there a reason why you're seting the OTADDR in >> tms570_initialize_and_clear if you're gonna overwrite it later in >> tms570_pom_remap (or, in our case, not use it at all)? I think simply >> setting TMS570_POM.GLBCTRL to zero would be clearer. > > The OT base address is global decision so even if following > region setup code is implemented such way, that it looks for > the first available POM region it has to allocate overlay > target in memory foolowing OT base address. So code reflect > this information that decision is global. If there more SRAM > memory reserved than even overlay target can be allocated > dynamically. I do not expect that we need such mechanism > soon or in middle time horizon. But I want to document hat. Ok. > The older version of Technical Refence Manual is unclear. > It take me some time to find the problem by comparison with > manuals for newer TMS570 family members when we introduced > TMS570 BSP. Manual version SPNU499B from November 2012 > (Revised August 2013) is already clear Indeed, I'd been reading SPNU499A. > Have you some plans to integrate or cooperate on bare (no loader) > startup code integration to mainline RTEMS BSP? It seems that > HalCoGen licensing has dramatically changed for latest versions > (so after review by others) it could be possible to reuse parts > of the generated code. Other option (may it be better fitting RTEMS > code style) is incrementally rewrite/write own code. We've always been on the side of cleaning up the Halcogen code and using that. That's what we're using right now, and it's working fine for us. I haven't looked at the TI license since last time we discussed this, but if it's now RTEMS-compatible then great. Keep in mind, though, that we're using a TMS570 USB kit (http://processors.wiki.ti.com/index.php/TMS570LS31x_USB_Kit), which may require different Halcogen code than your HDK. For instance, we set BSP_PLL_OUT_CLOCK to 180 MHz instead of the 160 you're using. If we're gonna migrate the Halcogen code, we should probably have a separate tree for each board. I currently don't know if we're gonna be able to contribute to the migration (if there's one). We'll get back to you on this. > If you intend to use 4.11 for production, please, test our changes > and suggest if they are appropriate for 4.11. Are you planning to merge this to 4.11? I don't know how the RTEMS team manages their branches, but I assumed any changes to 4.11 are bug-fixes instead of new features. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Mentors Wanted for Google Code In (High School Students)
Hi We need mentors to participate in the Google Code-In program. This is not a commitment like the Google Summer of Code. The focus is on high school students and smaller tasks any RTEMS user should be capable of performing. The tasks should take less than a day normally for the student. All contact will be via email. Mentoring is normally on a "first come, first served" basis. You answer email or review work when you can as students post it. We have done this twice in the past and it has been very rewarding. Please email me if you are curious and have questions or want to mentor. Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
PowerPC BSPs to Obsolete
Hi I would like to propose the some PowerPC BSPs be removed. I think ep1a and score603e can be safely removed. I think the mbx8xx is a possibility. There are three virtex BSPs and I don't know if any are possible candidates. A look at the history of ss555 shows one change that doesn't look like a horizontal sweep in 2013 and another by Eric Norum in 2004. Not sure about this one. Any others? -- Joel Sherrill, Ph.D. Check out RTEMS at https://www.rtems.org Truly free real-time operating system ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Trouble building RTEMS from master
On Nov 4, 2015 1:57 PM, "Gedare Bloom" wrote: > > Did you bootstrap -c and then bootstrap? I think I saw this error > earlier today too, with a new sparc toolchain, but then it went away > after i rm-rf'd my build tree and tried over. Hmm.. I thought I did that but am not sure. Maybe Martin can confirm. > On Wed, Nov 4, 2015 at 4:39 PM, Martin Galvan > wrote: > > Hi everyone! I'm currently having some trouble when building RTEMS > > from the git mainline. I'm using a toolchain built using (a fairly > > recent) RSB. My configure is: > > > > ../source/configure --target=arm-rtems4.11 > > --enable-rtemsbsp=beagleboneblack --enable-posix --enable-cxx > > --disable-networking --enable-tests=no > > > > However, when I run make, I get this: > > > > make[1]: *** No rule to make target `make/Templates/Makefile.lib', > > needed by `all-am'. Stop. > > > > I tried re-bootstraping and still see the same error. I saw this on a > > couple more BSPs (TMS570 and LPC1768). > > > > Notice this happens only with master; the 4.11 branch builds ok. > > > > Is this a bug, or am I doing something wrong? > > ___ > > 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 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Trouble building RTEMS from master
On Nov 4, 2015 1:39 PM, "Martin Galvan" < martin.gal...@tallertechnologies.com> wrote: > > Hi everyone! I'm currently having some trouble when building RTEMS > from the git mainline. I'm using a toolchain built using (a fairly > recent) RSB. My configure is: > > ../source/configure --target=arm-rtems4.11 > --enable-rtemsbsp=beagleboneblack --enable-posix --enable-cxx > --disable-networking --enable-tests=no > > However, when I run make, I get this: > > make[1]: *** No rule to make target `make/Templates/Makefile.lib', > needed by `all-am'. Stop. > > I tried re-bootstraping and still see the same error. I saw this on a > couple more BSPs (TMS570 and LPC1768). > > Notice this happens only with master; the 4.11 branch builds ok. > > Is this a bug, or am I doing something wrong? I saw this on SPARC sis and leon3 on the plane. I don't know why but it is a generic cross targrt bug. I didn't grep for the offending Makefile.am but expect it is a matter of deleting they one right line. ___ > 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: waf: Post-process object file
On 10/11/2015 8:35 pm, Sebastian Huber wrote: > Hello, > > for the libbsd we have the problem that we expose a lot of symbols from > the FreeBSD kernel space to the applications. There are several known > conflicts, e.g. FreeBSD log() vs. standard math library log(). The > current approach to solve this issue is to generate a file with lots of > > #define xx _bsd_xx > ... > > defines to rename at C pre-processor level. This is however quite > brittle and doesn't work in general. An alternative would be to > post-process the kernel-space object files with something like this > > objcopy --redefine-syms redefines.txt x.o > > with a redefines.txt > > xx=_bsd_xx > ... > > My question is now: how can I add this post-processing step to the waf > based libbsd build system? > Is this per object file or after the library has been made? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Add RTEMS 4.12 build set
On 10/11/2015 11:56 pm, Sebastian Huber wrote: > > > On 08/11/15 01:05, Chris Johns wrote: >> Are there any architecture regressions with gcc-6? > > m32c, moxie, v850 don't work with GCC 6. I thought moxie was building with a new binutils. > > epiphany and or1k still use non-FSF GCC. > Great. >> >> What archs have to actually run? > > arm, powerpc, sparc. > >> >> I am happy to move to gcc-6 for archs we know are working. For those >> that do not I am not so sure we should move them. > > The broken targets use the 4.11 configuration. > If there is no arch regressions I am happy with this. Can you please change the version default in rtems-tools? Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: waf: Post-process object file
On 11/11/15 08:33, Chris Johns wrote: On 10/11/2015 8:35 pm, Sebastian Huber wrote: >Hello, > >for the libbsd we have the problem that we expose a lot of symbols from >the FreeBSD kernel space to the applications. There are several known >conflicts, e.g. FreeBSD log() vs. standard math library log(). The >current approach to solve this issue is to generate a file with lots of > >#define xx _bsd_xx >... > >defines to rename at C pre-processor level. This is however quite >brittle and doesn't work in general. An alternative would be to >post-process the kernel-space object files with something like this > >objcopy --redefine-syms redefines.txt x.o > >with a redefines.txt > >xx=_bsd_xx >... > >My question is now: how can I add this post-processing step to the waf >based libbsd build system? > Is this per object file or after the library has been made? The library contains kernel and user space objects, so this is per object (kernel space objects). -- 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] Add RTEMS 4.12 build set
On 11/11/15 08:38, Chris Johns wrote: On 10/11/2015 11:56 pm, Sebastian Huber wrote: On 08/11/15 01:05, Chris Johns wrote: Are there any architecture regressions with gcc-6? m32c, moxie, v850 don't work with GCC 6. I thought moxie was building with a new binutils. /scratch/git-rtems-source-builder/rtems/build/moxie-rtems4.12-gcc-6-20151101-newlib-2.2.0.20151023-x86_64-linux-gnu-1/build/./gcc/xgcc -B/scratch/git-rtems-source-builder/rtems/build/moxie-rtems4.12-gcc-6-20151101-newlib-2.2.0.20151023-x86_64-linux-gnu-1/build/./gcc/ -nostdinc -B/scratch/git-rtems-source-builder/rtems/build/moxie-rtems4.12-gcc-6-20151101-newlib-2.2.0.20151023-x86_64-linux-gnu-1/build/moxie-rtems4.12/newlib/ -isystem /scratch/git-rtems-source-builder/rtems/build/moxie-rtems4.12-gcc-6-20151101-newlib-2.2.0.20151023-x86_64-linux-gnu-1/build/moxie-rtems4.12/newlib/targ-include -isystem /scratch/git-rtems-source-builder/rtems/build/moxie-rtems4.12-gcc-6-20151101-newlib-2.2.0.20151023-x86_64-linux-gnu-1/gcc-6-20151101/newlib/libc/include -B/build/rtems-4.12/moxie-rtems4.12/bin/ -B/build/rtems-4.12/moxie-rtems4.12/lib/ -isystem /build/rtems-4.12/moxie-rtems4.12/include -isystem /build/rtems-4.12/moxie-rtems4.12/sys-include-g -O2 -mel -O2 -I../../../../gcc-6-20151101/libgcc/../newlib/libc/sys/rtems/include -g -O2 -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -I. -I. -I../../.././gcc -I../../../../gcc-6-20151101/libgcc -I../../../../gcc-6-20151101/libgcc/. -I../../../../gcc-6-20151101/libgcc/../gcc -I../../../../gcc-6-20151101/libgcc/../include -DHAVE_CC_TLS -DUSE_EMUTLS -o _absvdi2.o -MT _absvdi2.o -MD -MP -MF _absvdi2.dep -DL_absvdi2 -c ../../../../gcc-6-20151101/libgcc/libgcc2.c -fvisibility=hidden -DHIDE_EXPORTS /tmp/ccvr1zIL.s: Assembler messages: /tmp/ccvr1zIL.s:20: Error: unknown opcode sub $r3,$r2 make[4]: *** [_ashrdi3.o] Error 1 make[4]: *** Waiting for unfinished jobs /tmp/cc3BXMUK.s: Assembler messages: /tmp/cc3BXMUK.s:20: Error: unknown opcode sub $r3,$r2 /tmp/cc5UNxWK.s: Assembler messages: /tmp/cc5UNxWK.s:26: Error: unknown opcode sub $r1,$r2 make[4]: *** [_lshrdi3.o] Error 1 make[4]: *** [_negdi2.o] Error 1 /tmp/cclz1cLL.s: Assembler messages: /tmp/cclz1cLL.s:20: Error: unknown opcode sub $r3,$r2 make[4]: *** [_ashldi3.o] Error 1 /tmp/cc2hrdNK.s: Assembler messages: /tmp/cc2hrdNK.s:43: Error: unknown opcode mul $r12,$r6 /tmp/cc2hrdNK.s:46: Error: unknown opcode mul $r8,$r6 /tmp/cc2hrdNK.s:48: Error: unknown opcode mul $r4,$r7 /tmp/cc2hrdNK.s:50: Error: unknown opcode mul $r1,$r7 /tmp/cc2hrdNK.s:52: Error: unknown opcode add $r1,$r8 /tmp/cc2hrdNK.s:59: Error: unknown opcode add $r3,$r1 /tmp/cc2hrdNK.s:65: Error: unknown opcode add $r4,$r1 /tmp/cc2hrdNK.s:73: Error: unknown opcode add $r1,$r4 /tmp/cc2hrdNK.s:86: Error: unknown opcode mul $r0,$r4 /tmp/cc2hrdNK.s:90: Error: unknown opcode mul $r2,$r4 /tmp/cc2hrdNK.s:92: Error: unknown opcode add $r0,$r2 /tmp/cc2hrdNK.s:96: Error: unknown opcode add $r0,$r12 /tmp/cc2hrdNK.s:97: Error: unknown opcode add $r1,$r2 make[4]: *** [_muldi3.o] Error 1 I already use Binutils 2.25. epiphany and or1k still use non-FSF GCC. Great. What archs have to actually run? arm, powerpc, sparc. I am happy to move to gcc-6 for archs we know are working. For those that do not I am not so sure we should move them. The broken targets use the 4.11 configuration. If there is no arch regressions I am happy with this. Can you please change the version default in rtems-tools? Does this break 4.11? -- 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
