Re: Math lib inclusion in BSP not required if CAN drivers are considered
Hi Pavel, Thanks for the detailed reply. I guess you aren't as "horribly out of time" as you said, or perhaps are no even more out of time :) We will definitely take a good look at the LinCAN source for baud rate calculations. The more I think about it, the more I think it's worth to port LinCAN to RTEMS, even though it wouldn't be the most trivial. Then we wouldn't have yet another CAN implementation that is subtly different than LinCAN. Here is the file in question: https://github.com/vecnatechnologies/rtems/blob/stm32-bsp-rebase-fixes/c/src/lib/libbsp/arm/shared/stm32f/can/hal-can.c Since I wrote it, I think it makes a lot of sense. However, I'll take a look at the LinCAN code some more and see if I can understand it. Again, thanks for the email. Isaac On 09/30/2015 06:08 PM, Pavel Pisa wrote: Hello Sudarshan, On Friday 25 of September 2015 19:13:53 sudarshan.rajagopalan wrote: On 2015-09-25 12:21, Daniel Gutson wrote: El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > On 2015-09-25 11:06, Daniel Gutson wrote: >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> >> wrote: >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). If this is part of CAN driver baudrate calculation then floating point is usually not required and can be sometimes harmfull because you need to find best matching ratio of integer numbers which are send to controller registers. See Linux SocketCAN implementation https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev.c?id=refs/tags/v4.3-rc3#n74 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/netlink.h?id=refs/tags/v4.3-rc3#n46 I have proposed it with structures defining CAN controller parameters many years ago and it seems that it has been enough for all controllers supported by Linux drivers. I suggest to not reinvent the wheel and use solution compatible with this one because you can use values already tested in the Linux kernel. As for the License, actual Linux code has been updated and enhanced by more people and is strict GPLv2 only. The main change is movement of sample point computation to the separate function can_update_spt() and change of sample point specification from 1/100 (%) to 1/1000 fractions. You can find simpler version in LinCAN driver code http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/lpc17xx_can.c#l90 http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/can/can_bittiming.h where LinCAN is released under license crated specially to be compatible with RTEMS as well. Generally, Volkswagen SocketCAN is intended to be available under BSD license in these parts where it does not directly interact with Linux kernel structures so I expect that there is no problem when some of Linux specific enhancements for bitrate calculation are reintroduced in our code. I check that directly with Linux CAN maintainers (Oliver Hartkopp, etc.). I have even userspace test code for these computations and some examples. I am horribly out of time this and next week but I can clean a dust from my memory and prepared files after this time and send the utility sources. But please, if you intend to have generic RTEMS CAN infrastructure, do not introduce floating point computation to CAN drivers and try to check if computations introduced by us initially for embedded system less applications and then selected by Linux kernel community can be used in RTEMS. It would really simplify new drivers and CAN HW introduction because you can use already elaborated values instead to reading complex chip manuals. Unfortuantelly, I cannot allocate time to RTEMS CAN as I would like. We have no project at university or company which would backup the work and there are still even higher priority "hobby" projects investments on my list - i.e. move forward (with my student) TMS570 BSP networking, QEMU CAN support and some motion control experimental stuff on RPi, Linux and our conceptually new solution for motor control current sensing, FPGA D-Q vector control and its combination with predictive control algorithms. Best wishes, Pavel ___ 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: Math lib inclusion in BSP not required if CAN drivers are considered
+1. - Sudarshan On 2015-10-01 11:06, Isaac Gutekunst wrote: Hi Pavel, Thanks for the detailed reply. I guess you aren't as "horribly out of time" as you said, or perhaps are no even more out of time :) We will definitely take a good look at the LinCAN source for baud rate calculations. The more I think about it, the more I think it's worth to port LinCAN to RTEMS, even though it wouldn't be the most trivial. Then we wouldn't have yet another CAN implementation that is subtly different than LinCAN. Here is the file in question: https://github.com/vecnatechnologies/rtems/blob/stm32-bsp-rebase-fixes/c/src/lib/libbsp/arm/shared/stm32f/can/hal-can.c Since I wrote it, I think it makes a lot of sense. However, I'll take a look at the LinCAN code some more and see if I can understand it. Again, thanks for the email. Isaac On 09/30/2015 06:08 PM, Pavel Pisa wrote: Hello Sudarshan, On Friday 25 of September 2015 19:13:53 sudarshan.rajagopalan wrote: On 2015-09-25 12:21, Daniel Gutson wrote: El 25/9/2015 13:17, "sudarshan.rajagopalan" escribió: > On 2015-09-25 11:06, Daniel Gutson wrote: >> On Thu, Sep 24, 2015 at 4:49 PM, sudarshan.rajagopalan >> >> wrote: >>> Hey all, >>> >>> We are developing a new BSP that uses math.h in few of the BSP files. I do >> May I ask why do you need floating point operations in a kernel? At >> least, what sort of operations and why not move them upwards. > > We are doing floating point operations in one of the device drivers as part of the BSP - to perform buadrate calculation, to be specific, which involes inverse operations and using roundf(). If this is part of CAN driver baudrate calculation then floating point is usually not required and can be sometimes harmfull because you need to find best matching ratio of integer numbers which are send to controller registers. See Linux SocketCAN implementation https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/net/can/dev.c?id=refs/tags/v4.3-rc3#n74 https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/can/netlink.h?id=refs/tags/v4.3-rc3#n46 I have proposed it with structures defining CAN controller parameters many years ago and it seems that it has been enough for all controllers supported by Linux drivers. I suggest to not reinvent the wheel and use solution compatible with this one because you can use values already tested in the Linux kernel. As for the License, actual Linux code has been updated and enhanced by more people and is strict GPLv2 only. The main change is movement of sample point computation to the separate function can_update_spt() and change of sample point specification from 1/100 (%) to 1/1000 fractions. You can find simpler version in LinCAN driver code http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/lpc17xx_can.c#l90 http://sourceforge.net/p/ortcan/lincan/ci/can-usb1/tree/embedded/app/usbcan/can/can_bittiming.h where LinCAN is released under license crated specially to be compatible with RTEMS as well. Generally, Volkswagen SocketCAN is intended to be available under BSD license in these parts where it does not directly interact with Linux kernel structures so I expect that there is no problem when some of Linux specific enhancements for bitrate calculation are reintroduced in our code. I check that directly with Linux CAN maintainers (Oliver Hartkopp, etc.). I have even userspace test code for these computations and some examples. I am horribly out of time this and next week but I can clean a dust from my memory and prepared files after this time and send the utility sources. But please, if you intend to have generic RTEMS CAN infrastructure, do not introduce floating point computation to CAN drivers and try to check if computations introduced by us initially for embedded system less applications and then selected by Linux kernel community can be used in RTEMS. It would really simplify new drivers and CAN HW introduction because you can use already elaborated values instead to reading complex chip manuals. Unfortuantelly, I cannot allocate time to RTEMS CAN as I would like. We have no project at university or company which would backup the work and there are still even higher priority "hobby" projects investments on my list - i.e. move forward (with my student) TMS570 BSP networking, QEMU CAN support and some motion control experimental stuff on RPi, Linux and our conceptually new solution for motor control current sensing, FPGA D-Q vector control and its combination with predictive control algorithms. Best wishes, Pavel ___ 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: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
On 1/10/2015 2:56 am, Sebastian Huber wrote: > diff --git a/wscript b/wscript > index 673479f..88334e4 100644 > --- a/wscript > +++ b/wscript > @@ -1053,42 +1053,41 @@ def build(bld): >'rtemsbsd/telnetd/pty.c', >'rtemsbsd/telnetd/telnetd.c'] > if bld.get_env()["RTEMS_ARCH"] == "arm": > -source += ['freebsd/sys/arm/arm/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] This looks wrong and checking git it is wrong. > if bld.get_env()["RTEMS_ARCH"] == "avr": > -source += ['freebsd/sys/avr/avr/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "bfin": > -source += ['freebsd/sys/bfin/bfin/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "cflags": > source += ['default'] > if bld.get_env()["RTEMS_ARCH"] == "h8300": > -source += ['freebsd/sys/h8300/h8300/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "i386": > source += ['freebsd/sys/i386/i386/in_cksum.c', > 'freebsd/sys/i386/i386/legacy.c', > 'freebsd/sys/x86/pci/pci_bus.c'] > if bld.get_env()["RTEMS_ARCH"] == "lm32": > -source += ['freebsd/sys/lm32/lm32/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "m32c": > -source += ['freebsd/sys/m32c/m32c/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "m32r": > -source += ['freebsd/sys/m32r/m32r/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "m68k": > -source += ['freebsd/sys/m68k/m68k/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "mips": > source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "nios2": > -source += ['freebsd/sys/nios2/nios2/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "powerpc": > source += ['freebsd/sys/powerpc/powerpc/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "sh": > -source += ['freebsd/sys/sh/sh/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "sparc": > -source += ['freebsd/sys/mips/mips/in_cksum.c', > - 'freebsd/sys/sparc/sparc/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "sparc64": > source += ['freebsd/sys/sparc64/sparc64/in_cksum.c'] > if bld.get_env()["RTEMS_ARCH"] == "v850": > -source += ['freebsd/sys/v850/v850/in_cksum.c'] > +source += ['freebsd/sys/mips/mips/in_cksum.c'] They all seem wrong which is a puzzling as to how this builds. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
Why do you think it is wrong? The background for this change is that we need an explicit one-to-one mapping of libbsd and original FreeBSD files. - Chris Johns schrieb: > On 1/10/2015 2:56 am, Sebastian Huber wrote: > > diff --git a/wscript b/wscript > > index 673479f..88334e4 100644 > > --- a/wscript > > +++ b/wscript > > @@ -1053,42 +1053,41 @@ def build(bld): > >'rtemsbsd/telnetd/pty.c', > >'rtemsbsd/telnetd/telnetd.c'] > > if bld.get_env()["RTEMS_ARCH"] == "arm": > > -source += ['freebsd/sys/arm/arm/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > This looks wrong and checking git it is wrong. > > > if bld.get_env()["RTEMS_ARCH"] == "avr": > > -source += ['freebsd/sys/avr/avr/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "bfin": > > -source += ['freebsd/sys/bfin/bfin/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "cflags": > > source += ['default'] > > if bld.get_env()["RTEMS_ARCH"] == "h8300": > > -source += ['freebsd/sys/h8300/h8300/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "i386": > > source += ['freebsd/sys/i386/i386/in_cksum.c', > > 'freebsd/sys/i386/i386/legacy.c', > > 'freebsd/sys/x86/pci/pci_bus.c'] > > if bld.get_env()["RTEMS_ARCH"] == "lm32": > > -source += ['freebsd/sys/lm32/lm32/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "m32c": > > -source += ['freebsd/sys/m32c/m32c/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "m32r": > > -source += ['freebsd/sys/m32r/m32r/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "m68k": > > -source += ['freebsd/sys/m68k/m68k/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "mips": > > source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "nios2": > > -source += ['freebsd/sys/nios2/nios2/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "powerpc": > > source += ['freebsd/sys/powerpc/powerpc/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "sh": > > -source += ['freebsd/sys/sh/sh/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "sparc": > > -source += ['freebsd/sys/mips/mips/in_cksum.c', > > - 'freebsd/sys/sparc/sparc/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "sparc64": > > source += ['freebsd/sys/sparc64/sparc64/in_cksum.c'] > > if bld.get_env()["RTEMS_ARCH"] == "v850": > > -source += ['freebsd/sys/v850/v850/in_cksum.c'] > > +source += ['freebsd/sys/mips/mips/in_cksum.c'] > > They all seem wrong which is a puzzling as to how this builds. > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel -- 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.huber at 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: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
On 2/10/2015 8:33 am, Sebastian Huber wrote: > Why do you think it is wrong? Because the check is for 'arm' and the file is 'mips'. Chris > > The background for this change is that we need an explicit one-to-one mapping > of libbsd and original FreeBSD files. > > - Chris Johns schrieb: >> On 1/10/2015 2:56 am, Sebastian Huber wrote: >>> diff --git a/wscript b/wscript >>> index 673479f..88334e4 100644 >>> --- a/wscript >>> +++ b/wscript >>> @@ -1053,42 +1053,41 @@ def build(bld): >>>'rtemsbsd/telnetd/pty.c', >>>'rtemsbsd/telnetd/telnetd.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "arm": >>> -source += ['freebsd/sys/arm/arm/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >> >> This looks wrong and checking git it is wrong. >> >>> if bld.get_env()["RTEMS_ARCH"] == "avr": >>> -source += ['freebsd/sys/avr/avr/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "bfin": >>> -source += ['freebsd/sys/bfin/bfin/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "cflags": >>> source += ['default'] >>> if bld.get_env()["RTEMS_ARCH"] == "h8300": >>> -source += ['freebsd/sys/h8300/h8300/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "i386": >>> source += ['freebsd/sys/i386/i386/in_cksum.c', >>> 'freebsd/sys/i386/i386/legacy.c', >>> 'freebsd/sys/x86/pci/pci_bus.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "lm32": >>> -source += ['freebsd/sys/lm32/lm32/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "m32c": >>> -source += ['freebsd/sys/m32c/m32c/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "m32r": >>> -source += ['freebsd/sys/m32r/m32r/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "m68k": >>> -source += ['freebsd/sys/m68k/m68k/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "mips": >>> source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "nios2": >>> -source += ['freebsd/sys/nios2/nios2/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "powerpc": >>> source += ['freebsd/sys/powerpc/powerpc/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "sh": >>> -source += ['freebsd/sys/sh/sh/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "sparc": >>> -source += ['freebsd/sys/mips/mips/in_cksum.c', >>> - 'freebsd/sys/sparc/sparc/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "sparc64": >>> source += ['freebsd/sys/sparc64/sparc64/in_cksum.c'] >>> if bld.get_env()["RTEMS_ARCH"] == "v850": >>> -source += ['freebsd/sys/v850/v850/in_cksum.c'] >>> +source += ['freebsd/sys/mips/mips/in_cksum.c'] >> >> They all seem wrong which is a puzzling as to how this builds. >> >> Chris >> ___ >> 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: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
- Chris Johns schrieb: > On 2/10/2015 8:33 am, Sebastian Huber wrote: > > Why do you think it is wrong? > > Because the check is for 'arm' and the file is 'mips'. The mips variant is generic (C code only). There is no functional change. Before this change we simply copied the file (one-to-N). -- 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.huber at 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: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
On 10/1/2015 2:38 PM, Chris Johns wrote: On 2/10/2015 8:33 am, Sebastian Huber wrote: Why do you think it is wrong? Because the check is for 'arm' and the file is 'mips'. If I recall correctly, the MIPS version is the most generic version and it is used for architectures which don't have their own. But with this change, that should be checked to be sure and comments added. Chris The background for this change is that we need an explicit one-to-one mapping of libbsd and original FreeBSD files. - Chris Johns schrieb: On 1/10/2015 2:56 am, Sebastian Huber wrote: diff --git a/wscript b/wscript index 673479f..88334e4 100644 --- a/wscript +++ b/wscript @@ -1053,42 +1053,41 @@ def build(bld): 'rtemsbsd/telnetd/pty.c', 'rtemsbsd/telnetd/telnetd.c'] if bld.get_env()["RTEMS_ARCH"] == "arm": -source += ['freebsd/sys/arm/arm/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] This looks wrong and checking git it is wrong. if bld.get_env()["RTEMS_ARCH"] == "avr": -source += ['freebsd/sys/avr/avr/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "bfin": -source += ['freebsd/sys/bfin/bfin/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "cflags": source += ['default'] if bld.get_env()["RTEMS_ARCH"] == "h8300": -source += ['freebsd/sys/h8300/h8300/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "i386": source += ['freebsd/sys/i386/i386/in_cksum.c', 'freebsd/sys/i386/i386/legacy.c', 'freebsd/sys/x86/pci/pci_bus.c'] if bld.get_env()["RTEMS_ARCH"] == "lm32": -source += ['freebsd/sys/lm32/lm32/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "m32c": -source += ['freebsd/sys/m32c/m32c/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "m32r": -source += ['freebsd/sys/m32r/m32r/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "m68k": -source += ['freebsd/sys/m68k/m68k/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "mips": source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "nios2": -source += ['freebsd/sys/nios2/nios2/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "powerpc": source += ['freebsd/sys/powerpc/powerpc/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "sh": -source += ['freebsd/sys/sh/sh/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "sparc": -source += ['freebsd/sys/mips/mips/in_cksum.c', - 'freebsd/sys/sparc/sparc/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "sparc64": source += ['freebsd/sys/sparc64/sparc64/in_cksum.c'] if bld.get_env()["RTEMS_ARCH"] == "v850": -source += ['freebsd/sys/v850/v850/in_cksum.c'] +source += ['freebsd/sys/mips/mips/in_cksum.c'] They all seem wrong which is a puzzling as to how this builds. Chris ___ 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 -- 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
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
On 1/10/2015 11:46 am, Pavel Pisa wrote: > Hello Chris and others, > > I have no problem if most of RTEMS makefiles are replaced by something > better but I would really regret if > > /opt/rtems4.11/arm-rtemsX.YY/BSP_Z/Makefile.inc > > file is not generated and installed during BSP build process. > Please see my response on the devel list to this issue... https://lists.rtems.org/pipermail/devel/2015-September/012646.html > This file holds enough information to build complex application > with same setting as is the one used to build BSP. This is an important requirement for the generation of code for all build systems and not just users of make. There are also warnings and other settings used in RTEMS and BSPs that get exported and these should not. These exported flags break a number of 3rd party libraries. I have code in a number of places to filter flags into groups so builds works. > And I would prefer if these variables values are preserved > after install in some form which can be directly read by GNU make. As I state in my devel list post we will provide a specific tool to manage the interface and when the time comes I suggest Makefile support is built around that interface. > I can imagine calling some pkgconfig like tool to obtain these > values but it would mean that we have to run that tool once > and store/cache results somewhere in the build to not suffer from > overhead to call the tool when make is parsing makefile in each > directory. I am sorry but I have no feel for the performance issues involved. I appreciate we need to be mindful of the impact on users and any added complexity such as caches (shudder). I can only offer we work together to find a suitable solution that works for everyone and meets the new broader requirements RTEMS has these days. > The question is if to keep /opt/rtems4.11/make/custom . If defines > are directly inlined in BSP specific Makefile.inc it can > be even better. Where does this leave other build systems? What if each build system's users start to request custom support? Allowing custom support adds an extra burden to the RTEMS maintainers to make sure no one breaks. RTEMS developers are not build system experts so this just dilutes our efforts. We need to find a suitable middle ground for everyone. > May it be that I am too afraid of changes. But example which > I fear off is my experience with MBED testing. It uses python > based build system or provides Eclipse integration. I have not been > able to integrate it with our build system yet even that base MBED > build only generates libraries as RTEMS does. But it is optimized > to generate Makefiles based packages as partial distributions > for companies EDKs but not for install and use from own applications. > Used compiler parameters are hidden in python based build system > or in complete but easily not reusable makefiles generated for given > exported example. I completely understand and wish to avoid the experiences you describe. What you describe I have been fighting but with RTEMS for years. I do not use the make support for RTEMS and have not for years and it is not fun keeping things going. > We cannot switch to WAF only build for our application code > because it would not support Linux userspace and kernelspace, > about 20 different systemless embedded hardware targets from > H8S, nRF51, LPC, MSP430 etc. and crosscompile to RTEMS > and Linux on more archs from single source submodules > trees usually symlinked at toplevel of target specific > build tree. No one is asking you to most of all me. I want RTEMS to support any build system just not directly. > So, please, do not hide basic setting. Store it in some > simple human and make readable form in BSP install directory > as a list of assignments. There is not much more required > to build application if these values are exported. We need to provide an interface we can maintain and we need to make it suitable for all users including you. My fear of a specific file format is expanding the work RTEMS has making sure the file and it's format does not break users. Make gets used in complex and fragile ways and issues can be subtle. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
On 2/10/2015 9:15 am, Joel Sherrill wrote: > > > On 10/1/2015 2:38 PM, Chris Johns wrote: >> On 2/10/2015 8:33 am, Sebastian Huber wrote: >>> Why do you think it is wrong? >> >> Because the check is for 'arm' and the file is 'mips'. > > If I recall correctly, the MIPS version is the most generic > version and it is used for architectures which don't have > their own. Is this how FreeBSD uses the code? > But with this change, that should be checked to be sure > and comments added. I suppose no one can change the mips code which means that name is meaning less as well. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-libbsd commit] builder.py: addTargetSourceCPUDependentSourceFiles
On 10/1/2015 3:34 PM, Chris Johns wrote: On 2/10/2015 9:15 am, Joel Sherrill wrote: On 10/1/2015 2:38 PM, Chris Johns wrote: On 2/10/2015 8:33 am, Sebastian Huber wrote: Why do you think it is wrong? Because the check is for 'arm' and the file is 'mips'. If I recall correctly, the MIPS version is the most generic version and it is used for architectures which don't have their own. Is this how FreeBSD uses the code? No. FreeBSD has no concept of many of the architectures we support. And for some we support that FreeBSD does not, we have our own optimized versions thanks to years of the IPV4 stack. But with this change, that should be checked to be sure and comments added. I suppose no one can change the mips code which means that name is meaning less as well. We could specifically important is "default" or something and make architectures without specific support use that single copy. Then there is only the knowledge that we picked X to be the default implementation. Ultimately, you have to have an implementation. When there is not one, we have to provide a reasonable implementation in C. And we will always have architectures in this boat. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
Chris, Makefile isn’t custom support, it’s legacy support. For better or for worse, if you add barriers to Makefiles you raise eyebrows in the legacy community. They can understand an effort to adapt from BSD make to GNU make, but a lack of Makefile support is a check-box not checked. I don’t know of any other build systems that have the footprint of “make”. Yes, the twisty auto* mess is a mess, but it does promise Makefile support. If you think time has passed this issue by I’d like to know, I don’t think it has. > On Oct 1, 2015, at 16:27 , Chris Johns wrote: > > Where does this leave other build systems? What if each build system's > users start to request custom support? Allowing custom support adds an > extra burden to the RTEMS maintainers to make sure no one breaks. RTEMS > developers are not build system experts so this just dilutes our > efforts. We need to find a suitable middle ground for everyone. Peter - Peter Dufault HD Associates, Inc. Software and System Engineering This email, like most email, is delivered unencrypted via internet email protocols subject to interception and tampering. Contact HDA to discuss methods we can use that ensure secure communication. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: How will user's compile with Makefiles? Was: Re: large bss size for sample applications
Hello all, On Thursday 01 of October 2015 23:59:05 Peter Dufault wrote: > Chris, Makefile isn’t custom support, it’s legacy support. For better or > for worse, if you add barriers to Makefiles you raise eyebrows in the > legacy community. They can understand an effort to adapt from BSD make to > GNU make, but a lack of Makefile support is a check-box not checked. I > don’t know of any other build systems that have the footprint of “make”. > > Yes, the twisty auto* mess is a mess, but it does promise Makefile support. In the fact, I think there is no replacement generic enough for autoconf. But it can be used without automake, for example GIT uses this setup. As for RTEMS, I do not mind if automake and autoconf are eliminated. I have stuck on simple atempt to copy of rtems/testsuites/libtests/tar02 to rtems/testsuites/samples/tar02 now. I hoped to speedup that way preparation of testcase for untar 4.11 regression (build RTEMS only with --enable-tests=samples). But for some reasons bootstrap/automake does not understand my intention. And generally, I do not like automake too much. On the other hand, there are many clean (GNU) make based large projects - Linux kernel etc. In that regard, I like much Linux kernel configuration system which allows to configure complex combinations of options with interdependencies. More projects use standalone version of these tools with their (usually make based) build systems http://ymorin.is-a-geek.org/projects/kconfig-frontends Important is that whole selected configuration is stored in human readable form and can be versionned. But CMAKE combined with Ninja seems to work well for ReactOS and there exist much more well working options. As for RTEMS BSP parameters, my preference is if they are stored in clean, human and tools readable form after installation. The current make compatible format (i.e. lines KEY=VALUE) looks to me as sane. I have some fear if that information is installed in form of some algorithm/tool even common to more BSPs that I cannot be confident with long term guaranteed exact match to the values used during BSP build. There is not so much required. I.e. values for CC or CC_FOR_TARGET, etc. (AS, AR, LD ..), CFLAGS, CPPFLAGS, LDFLAGS and LIBS. The most other is in bsp_specs and linkcmds. Or is it expected to remove these as well? Where is expected be stored this infomation in the new build system after BSP install? Best wishes, Pavel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
