Re: RTEMS+LWIP for LPC1768 BSP
On 8/11/2014 12:50 am, Marcos Díaz wrote: On Thu, Nov 6, 2014 at 6:26 PM, Joel Sherrill mailto:joel.sherr...@oarcorp.com>> wrote: On 11/4/2014 3:01 PM, Marcos Díaz wrote: Hi! We are currently using a LWIP implementation on the Beagle Bone Black bsp, recently uploaded by Ben Gras. We developed this port based on ethernet and lwip drivers from StarterWare drivers of Texas Instrument. We took this port, that was intended for baremetal use and added a posix implementation, as Federico did for the semaphores, messages and threads to use inside LWIP and the driver, and updated LWIP version to the current working branch. We also modified the device driver in order to support threads in charge of managing the input and output of the device. The license for those drivers is BSD and copied from the LWIP's BSD license. Now we are using this port as an application, but we wanted to have ideas of how we can put LWIP inside RTEMS. I'm thinking of many things, as: initialization of the device I assume it is just a subroutine call to LWIP and the application would make it at the appropriate time. This is like the current IPV4 stack. The new IPV4/IPV6 stack has a slightly different startup mechanism and can use BSD type commands like ifconfig and route to configure it. configuration of lwip options and ip address options The old and new stacks already do this differently. I suspect that initializing the selected stack in a uniform way isn't as critical as not having N versions of services like httpd, telnetd, etc. In our case, as an example, we have two boards with a port to lwip: the beagle bone black and the lpc1768. The first one has enough resources to enable a big memory pool and all the services of the stack, but on the second one, you cannot have all that you want because of its limited resources. I'm thinking on per BSP lwip options files or something like that. use of socket api and integrating it to the libraries used in RTEMS. Is the code posted somewhere? How much has been submitted upstream to LWIP? We haven't submitted this port to lwip yet, we want to make some more testing. It might pay to give the maintainers a peek so they know what is coming. With the old IPV4 stack, new IPV4/IPV6 stack, and LWIP stack all available in parallel, it may make sense to NOT merge LWIP directly but consider networking as an add-on package. Assuming we break the old stack out of the main source tree into an independent package, then you would build RTEMS, a networking kit, etc. The RSB's notion of packages for RTEMS makes this pretty attractive. where can I take a look of examples of RSB packages? I will outline the process using the libjpeg library Joel recently added support for. The top user level is the libjpeg build set file for RTEMS 4.11. The file is 'rtems/config/4.11/graphics/libjpeg.bset'. This file includes the version specific configuration file for building libjpeg called 'rtems/config/graphics/libjpeg-9a-1.cfg'. The configuration file defines the version number and the hash for the source plus anything else specific to the build for RTEMS and then it includes the generic build recipe 'source-builder/config/libjpeg-1.cfg'. This configuration is in the common build recipe directory and could be used by a bare configuration for an elf only target such as arm-elf. The recipe follows the standard for these files. I suggest you have a look at a few to see how these work. There is documentation as well in the doc directory. So, the Idea is basically to submit the stack as an extern application, am I correct? Not a static library your application links too. The process may require a number of libraries to come together to work. I would have LWIP built to a library without any other other code. How we will manage that there is common code (the lwip stack) and bsp specific code (initialization and low level drivers). I do not know how LWIP manages the BSP and driver specific code. If they cannot be not placed in their code base we will need to create something to handle this. We would need to build a library of the code against the LWIP library and the user would have 2 static libraries to link to, eg liblwip.a and liblwipbsp.a. The examples-v2 has waf support that lets you do specific things for a BSP. You could detect the specific BSP or family of BSPs and then build the required drivers. The waf support uses the RTEMS waf support and this knows about archs and bsps. The RBS build sets would glue all this together. In this case the build set would build the LWIP package and the LWIPbsp package. The 4.11/rtems-arm etc build set files show how packages are combined to create a single package. If you take the 4.11/rtems-arm build set you will see devel/expat-2.1.0-1 package. It is a library that is built and the
Re: rtems-tools: Fix libpath failed for rtems-ld
On 8/11/2014 1:39 pm, Peng Fan wrote: we should not clear input parameter 'se' in rld::split, otherwise paths passed using '--lib-path' to rtems-ld will be cleared if standlibs are used. Thanks for this. I also have a patch for this in my repo. I will push it once git has been relocated and writes are enabled again. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-tools: Fix libpath failed for rtems-ld
Hi, we should not clear input parameter 'se' in rld::split, otherwise paths passed using '--lib-path' to rtems-ld will be cleared if standlibs are used. Regards, Peng. 0001-Not-clear-input-parameter-se-in-rld-split.patch Description: Binary data ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS+LWIP for LPC1768 BSP
On Thu, Nov 6, 2014 at 6:26 PM, Joel Sherrill wrote: > > On 11/4/2014 3:01 PM, Marcos Díaz wrote: > > Hi! > We are currently using a LWIP implementation on the Beagle Bone Black > bsp, recently uploaded by Ben Gras. > We developed this port based on ethernet and lwip drivers from StarterWare > drivers of Texas Instrument. > We took this port, that was intended for baremetal use and added a posix > implementation, as Federico did for the semaphores, messages and threads to > use inside LWIP and the driver, and updated LWIP version to the current > working branch. > We also modified the device driver in order to support threads in charge > of managing the input and output of the device. > The license for those drivers is BSD and copied from the LWIP's BSD > license. > > Now we are using this port as an application, but we wanted to have > ideas of how we can put LWIP inside RTEMS. > I'm thinking of many things, as: > initialization of the device > > I assume it is just a subroutine call to LWIP and the application would > make it at the appropriate time. This is like the current IPV4 stack. > > The new IPV4/IPV6 stack has a slightly different startup mechanism > and can use BSD type commands like ifconfig and route to configure it. > > configuration of lwip options and ip address options > > The old and new stacks already do this differently. I suspect that > initializing the selected stack in a uniform way isn't as critical > as not having N versions of services like httpd, telnetd, etc. > In our case, as an example, we have two boards with a port to lwip: the beagle bone black and the lpc1768. The first one has enough resources to enable a big memory pool and all the services of the stack, but on the second one, you cannot have all that you want because of its limited resources. I'm thinking on per BSP lwip options files or something like that. > > > > use of socket api and integrating it to the libraries used in RTEMS. > > Is the code posted somewhere? How much has been submitted > upstream to LWIP? > We haven't submitted this port to lwip yet, we want to make some more testing. > > With the old IPV4 stack, new IPV4/IPV6 stack, and LWIP stack > all available in parallel, it may make sense to NOT merge > LWIP directly but consider networking as an add-on package. > > Assuming we break the old stack out of the main source tree > into an independent package, then you would build RTEMS, > a networking kit, etc. The RSB's notion of packages for RTEMS > makes this pretty attractive. > where can I take a look of examples of RSB packages? So, the Idea is basically to submit the stack as an extern application, am I correct? How we will manage that there is common code (the lwip stack) and bsp specific code (initialization and low level drivers). > > So, we want to get some ideas as when and where we can set this > configurations and functions inside RTEMS. > Thanks, and feel free to ask any questions about the work we did. > > On Thu, Aug 28, 2014 at 2:27 PM, Federico Casares < > federico.casa...@tallertechnologies.com> wrote: > >> Hi, >> >> On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill < >> joel.sherr...@oarcorp.com> wrote: >> >>> First. Thanks for the work and taking the time and effort to >>> submit it. >>> >>> Specifics below, but the general answer is to submit all RTEMS >>> changes as reviewable patches to devel@rtems.org. We can >>> then review them and get them merged. This will leave us >>> with just the LWIP changes. >>> >>> Then we can review those and begin to work with that community >>> to get them merged. >>> >>> >>> >>> On 8/26/2014 6:22 AM, Federico Casares wrote: >>> >>> Hi, >>> >>> In the past weeks we were working on porting the last LWIP version to >>> RTEMS for >>> the LPC1768 microcontroller. Our main goal was to accomplish this with >>> the >>> minimum number of changes for both projects. Fortunately, the result was >>> positive. >>> >>> Now, we are capable of providing to the community with this new version >>> of the >>> RTEMS+LWIP port. In details: >>> >>> - RTEMS: last git revision = baa3c91ecb8a3b48ef387b938fcdb6 >>> e60b5bdc8a >>> - LWIP: last git revision = 63038e03055183e3bc043711ada1de3bb907e989 >>> - LPC1768: based on MBED driver = >>> https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP >>> >>> >>> The list of changes follows: >>> >>> - RTEMS OS: No changes were needed here. Despite this we will be posting >>> a >>> possible improvement in the newlib maillist soon. It consist in adding >>> the gcc >>> function attribute "warn_unused_result" to the pthread_*_init functions. >>> As a >>> result, developers will be warned about checking the return value. NOTE: >>> a >>> common error here could be not checking the return value, assuming a >>> successful >>> result, and trying to, for example, lock a mutex which init function has >>> returned ENOMEM. (We found this exact mistake in the current LWIP OS >>> layer >>> implementati
Re: Is there plan for stable 4.10.3 release branching?
On November 7, 2014 12:50:03 AM CST, Chris Johns wrote: >On 7/11/2014 4:05 am, Joel Sherrill wrote: >> >> Also Chris has RSB support for 4.10 tools so he should also comment >to make sure he thinks it is ready. >> > >The 4.10 released binaries still exist and I have fixed all reported >4.10 issues. I would like to use RSB built binaries and build all BSPs. >> This will also be a good exercise for the new hosting. > >Yes this is a great idea. The file Makefile.maint in the top rtems directory has the scripting for generating releases, tagging, generating version file, etc for CVS. We need the equivalent, a script in rtems tools, or a manual procedure to cut a release now with git. Obviously I prefer a repo independent script. >Chris --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
