On 8/11/2014 12:50 am, Marcos Díaz wrote:
On Thu, Nov 6, 2014 at 6:26 PM, Joel Sherrill <joel.sherr...@oarcorp.com
<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
then referenced in the building of gdb that. This is similar to what you
would want to do.
Chris
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
