RTEMS+LWIP for LPC1768 BSP

[Chris Johns]

On 8/11/2014 12:50 am, Marcos Díaz wrote:
>
>
> On Thu, Nov 6, 2014 at 6:26 PM, Joel Sherrill <joel.sherrill at oarcorp.com
> <mailto:joel.sherrill at 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 
then referenced in the building of gdb that. This is similar to what you 
would want to do.

Chris