Hi all, any news on this?
Managed to run SOEM on qemu with some help. It was on an arm guest and successfully talked to 3 slaves. I will try to push the SOEM changes upstream as well this week. Cheers, Niko. On Tue, Sep 19, 2017 at 10:08 AM, Nicolas Tsiogkas <lou.n...@gmail.com> wrote: > Hi, > > I made the required changes and got SOEM to compile. It is still untested > and I'm getting the following error, but the library builds well. > > RTEMS Source Builder - Set Builder, 4.11 (7db7be3ae7e0 modified) > Build Set: 4.11/net/soem > config: net/soem.cfg > package: soem-sparc-rtems4.11-1 > git: clone: git://github.com/lounick/SOEM.git -> sources/git/SOEM.git > git: checkout: git://github.com/lounick/SOEM.git => integrate-with-RTEMS > building: soem-sparc-rtems4.11-1 > error: copying tree: /home/niko/rtems/rsb/rtems/ > build/tmp/soem-sparc-rtems4.11-1-root-niko -> /home/niko/rtems/rsb/rtems/ > build/tmp/sb-niko/4.11/net/soem: [Errno 2] No such file or directory: > '/home/niko/rtems/rsb/rtems/build/tmp/soem-sparc-rtems4.11-1-root-niko' > Build Set: Time 0:00:02.307659 > Build FAILED > > I will be attending a conference and won't be able to work on it till the > end of the month. I am attaching the patch plus the build log in case > someone has time to give it a try and find any issues. Else I will try to > test it once I'm back. > > Cheers, > Niko > > On Mon, Sep 11, 2017 at 3:19 PM, Joel Sherrill <j...@rtems.org> wrote: > >> >> >> On Mon, Sep 11, 2017 at 7:26 AM, Nicolas Tsiogkas <lou.n...@gmail.com> >> wrote: >> >>> Hi Chris, >>> >>> minor update on the progress. >>> >>> I managed to start the compilation correctly on Friday. Of course it >>> fails as the source needs to be modified. >>> >> >> Hopefully it is not much and it is ways in which they assumed Linux not >> POSIX >> or not deeply embedded. Feel free to ask questions on issues. You tend to >> see similar issues over and over. >> >> >>> >>> On that front I haven't heard back from people responsible for the >>> ethernet driver and if libbsd is in their scope. >>> >> >> From a porting perspective, I would not worry about this. The package >> should be written to the >> standard networking APIs. The legacy stack or libbsd will have the same >> core APIs although >> libbsd will have a more complete set and have a more recent and robust >> set of device drivers. >> >> NOTE: The pc support needs updating. It broke when the core libbsd code >> was last >> updated to be using a later FreeBSD version. There should be a ticket >> describing >> the issue. I don't know if this impacts you or not. >> >> >>> >>> In general which are the options? Libbsd and standard RTEMS networking >>> stack? I will try to evaluate both and have something compiling by Friday >>> hopefully, so I can test and create the patches. >>> >> >> Yes. The stack in the RTEMS tree is an older FreeBSD port with IPV4 only >> and a limited set of newer device drivers. A lot of the older BSPs have >> device >> drivers for it. It is missing a few POSIX network APIs but that doesn't >> seem to >> have ever caused anyone issues. >> >> The new libbsd stack is much more modern, feature, uses standard FreeBSD >> network drivers, IPV4, IPV6, etc. It also includes USB host and early Wifi >> support. >> >> If at all possible you want to use the libbsd stack. But for the purposes >> of porting/compiling alone, it doesn't matter much. Thanks to careful >> engineering, with RTEMS you use the same header files independent >> of the underlying stack. Port to one and you should have a port to >> the other until it comes to actual network configuration issues. >> >> --joel >> >> >>> >>> Cheers, >>> Niko >>> >>> On Thu, Sep 7, 2017 at 5:40 PM, Nicolas Tsiogkas <lou.n...@gmail.com> >>> wrote: >>> >>>> Thanks Chris for your input. >>>> >>>> I think I've used a cmake gui once in 2008 or 2009 and never did that >>>> to myself again. :P >>>> >>>> I started creating the required cmake extensions for SOEM. I hope to >>>> have something trying to compile by monday sometime. I'll keep you posted. >>>> >>>> Cheers, >>>> Niko >>>> >>>> On Thu, Sep 7, 2017 at 3:57 AM, Chris Johns <chr...@rtems.org> wrote: >>>> >>>>> On 06/09/2017 19:56, Nicolas Tsiogkas wrote: >>>>> > I'm trying to integrate SOEM with RTEMS ( >>>>> https://devel.rtems.org/ticket/3120 >>>>> > <https://devel.rtems.org/ticket/3120>) >>>>> >>>>> Thank you for creating the ticket. >>>>> >>>>> > As I am trying to create the appropriate bset and cfg files I >>>>> noticed that all >>>>> > the packages built are based on autoconf to be built. >>>>> >>>>> This reflects the nature of the packages we currently support and >>>>> nothing more. >>>>> >>>>> > SOEM on the other hand is only providing CMake as a build tool. >>>>> >>>>> This should be fine if the implementation in SOEM is ok. >>>>> >>>>> > I have found instructions on using CMake with RTEMS >>>>> > (https://lists.rtems.org/pipermail/devel/2016-March/013800.html) >>>>> > >>>>> > The question is if it would be more sensible to create a build >>>>> environment for >>>>> > SOEM based on autotools or try to use CMake somehow? >>>>> >>>>> I do not think there is a need. The upstream project has selected >>>>> cmake and we >>>>> should respect that. >>>>> >>>>> > I doubt that changing the build system will be easily accepted >>>>> upstream. >>>>> >>>>> Agreed. >>>>> >>>>> The RSB scripts will invoke cmake so this bit is easy. The part you >>>>> need to work >>>>> with the upstream project is getting a cross-complier build to work. >>>>> How well >>>>> this works depends on how the cmake build scripts in the project are >>>>> implemented. Carefully constructed cmake build scripts and the >>>>> judicious use of >>>>> the command line `-D` options can be used to configure and/or build >>>>> the package. >>>>> >>>>> I should warn you, use the cmake gui and tui tool at your own risk, if >>>>> you step >>>>> in there you may never return as the same person. >>>>> >>>>> The key file in the RSB is rtems-bsp.cfg [1]. It wraps a private >>>>> package config >>>>> implementation that parses an installed BSP's build configuration [2] >>>>> and >>>>> updates the internal RSB data [3]. >>>>> >>>>> I suggest you get the package to build from the command line for a >>>>> BSP. This >>>>> will be the compiler name and cflags. What you end up with will be >>>>> available in >>>>> the macros in rtems-bsp.cfg. >>>>> >>>>> Have a look in the BSP installed .pc file for the flags to use, ie do >>>>> a `find . >>>>> -name \*.pc` from the RTEMS installed prefix path. >>>>> >>>>> My (publicly denied) cmake experience with RTEMS is configure header >>>>> tests can >>>>> be fragile if there is cmake nesting. >>>>> >>>>> Chris >>>>> >>>>> [1] https://git.rtems.org/rtems-source-builder/tree/rtems/config >>>>> /rtems-bsp.cfg >>>>> [2] https://git.rtems.org/rtems-source-builder/tree/rtems/config >>>>> /rtems-bsp.cfg#n64 >>>>> [3] https://git.rtems.org/rtems-source-builder/tree/rtems/config >>>>> /rtems-bsp.cfg#n81 >>>>> >>>> >>>> >>> >>> _______________________________________________ >>> 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
