RTEMS+LWIP for LPC1768 BSP

Joel Sherrill joel.sherrill at oarcorp.com
Thu Nov 6 21:26:06 UTC 2014


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.
> 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?

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.
> 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.casares at tallertechnologies.com
> <mailto:federico.casares at tallertechnologies.com>> wrote:
>
>     Hi,
>
>     On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill
>     <joel.sherrill at oarcorp.com <mailto:joel.sherrill at 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 at rtems.org
>         <mailto:devel at 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
>>         implementation for Unix)
>>
>         FWIW the gcc C++ library adapters for threading do not check
>         the results from
>         those operations. This is an open sore spot for us.
>>         - RTEMS LPC1768_MBED BSP: We added a new section to the
>>         linker script, so we
>>         were able to put the LWIP and driver buffers in an exact
>>         memory location (useful
>>         when working with DMA devices).
>>
>         This sounds like a discrete patch to submit to devel at rtems.org
>         <mailto:devel at rtems.org>.
>
>     Already sent.
>
>>         - RTEMS LPC1768_MBED Ethernet Driver: Based on an existing
>>         driver from MBED, we
>>         ported it to RTEMS. NOTE: we will be creating our own driver
>>         in the near future.
>>
>         What is the license of these drivers?
>
>     GPLv2. Is this ok?
>
>>         - LWIP: As mentioned previously, we needed to put all LWIP
>>         buffers in DMA memory
>>         locations. Consequently, we added the "section" attribute to
>>         LWIP ram_heap and
>>         memp_memory buffers. Furthermore, as this is a common
>>         strategy in embedded
>>         devices with DMA, we made it generic and we will send these
>>         changes to the LWIP
>>         project. Additionally, we will provide some minor
>>         adds/changes to the lwip log
>>         system and statistics system.
>>
>         OK. Those are obviously their's to review. :)
>
>>         - LWIP-contrib: Some of the changes/adds were: fixing some
>>         issues related with
>>         posix initialization checks and allow set threads stack size.
>>
>         What all specific to RTEMS was added? Do you want RTEMS
>         Community review
>         on this?
>
>         Is there a readme/howto to configure and use LWIP on RTEMS?
>
>         It sounds like the port is largely BSP independent. Is this
>         the case?
>
>     See below.
>
>>         - LWIP-test-app: A simple TCP echo server with debugging
>>         functionality
>>         (rtems malloc statistics, rtems stack checker, lwip
>>         statistics, driver
>>         statistics and registers dump) available.
>>
>         Very cool!
>
>         How large was the code/data/RAM use of the test application?
>
>     $ arm-rtems4.11-size -A -d o-optimize/lwip.exe
>
>     o-optimize/lwip.exe  :
>     section              size        addr
>     .start                840           0
>     .text              138000         840
>     .init                  12      138840
>     .fini                  12      138852
>     .rodata             14704      138864
>     .ARM.exidx              8      153568
>     .eh_frame               4      153576
>     .init_array             4      153580
>     .fini_array             4      153584
>     .jcr                    4      153588
>     .vector              1256   268435456
>     .data                1568   268436712
>     .bss                 8500   537378816
>     .work               29944   268438280
>     .eth                16312   537395200
>     .comment              109           0
>     .debug_aranges      15608           0
>     .debug_info       2525968           0
>     .debug_abbrev      290957           0
>     .debug_line        897089           0
>     .debug_frame        34048           0
>     .debug_str         384335           0
>     .debug_loc         271111           0
>     .debug_ranges       19536           0
>     .debug_macro       516169           0
>     .ARM.attributes        41           0
>     Total             5166143
>
>     (gdb) p Configuration
>     $1 = {work_space_size = 13640, stack_space_size = 3808,
>     maximum_extensions = 0, maximum_keys = 1, maximum_key_value_pairs
>     = 0, microseconds_per_tick = 1000, nanoseconds_per_tick = 1000000,
>     ticks_per_timeslice = 20,
>       idle_task = 0x16195 <_CPU_Thread_Idle_body>,
>     idle_task_stack_size = 200, interrupt_stack_size = 0,
>     stack_allocate_init_hook = 0x0 <bsp_start_vector_table_begin>
>     , stack_allocate_hook = 0x15f61 <_Workspace_Allocate>,
>       stack_free_hook = 0x15f89 <_Workspace_Free>,
>     do_zero_of_workspace = false, unified_work_area = false,
>     stack_allocator_avoids_work_space = false,
>     number_of_initial_extensions = 3, User_extension_table = 0x247e4
>     <Configuration_Initial_Extensions>}
>      
>
>>
>>         As this new port is comprised of several patches and adds, it
>>         would be great
>>         to have some advice in how to proceed. We can provide you
>>         with the project as a
>>         whole or divided into independent patches. Also, we will need
>>         to know which
>>         parts of the port are of RTEMS interest to be submitted.
>>
>         RTEMS needs to nibble and digest the RTEMS stuff. That sounds
>         pretty easy.
>
>         Then we can help or at least track and provide help getting
>         the LWIP port
>         reviewed and merged by them.
>
>
>
>     This project can be divided into 4 main parts:
>
>     1) RTEMS
>     2) LWIP
>     3) LWIP driver
>     4) User application
>     Even though this project was developed for the LPC1768, almost all
>     can be used for
>     other devices, with the obvious exception of the driver.
>
>     As I told you, we tried to do this with minimum changes, and you
>     will see that. The only
>     pieces of code that are completely new (for RTEMS and LWIP) are
>     the driver and the
>     demo application.
>
>     So, for each part:
>
>     1) I will submit the change related to the linker script today,
>     and we will be working in
>     the "GCCattributes" to send it to newlib.
>     2) Should RTEMS have a version of LWIP in their building system?
>     (maybe as an external
>     library) so anyone can use it for their projects?
>     3) The driver is LWIP dependent and, as LWIP sources does not
>     contains any kind of
>     driver,should we add this driver to the LPC1768 dsp implementation
>     of RTEMS?.
>     4) Should we add this application example to the list of RTEMS
>     testsuites/samples?
>
>     Regards.
>
>      
>
>
>>         Regards.
>>
>>
>>         -- 
>>         http://www.tallertechnologies.com
>>         <http://www.tallertechnologies.com>
>>         Casares, Federico
>>         Sr. Software Engineer
>>         Taller Technologies Argentina
>>
>>         San Lorenzo 47, 3rd Floor, Office 5
>>         Córdoba, Argentina
>
>         -- 
>         Joel Sherrill, Ph.D.             Director of Research & Development
>         joel.sherrill at OARcorp.com <mailto:joel.sherrill at OARcorp.com>        On-Line Applications Research
>         Ask me about RTEMS: a free RTOS  Huntsville AL 35805
>         Support Available                (256) 722-9985
>
>
>
>
>     -- 
>     http://www.tallertechnologies.com <http://www.tallertechnologies.com>
>     Casares, Federico
>     Sr. Software Engineer
>     Taller Technologies Argentina
>
>     San Lorenzo 47, 3rd Floor, Office 5
>     Córdoba, Argentina
>
>     _______________________________________________
>     devel mailing list
>     devel at rtems.org <mailto:devel at rtems.org>
>     http://lists.rtems.org/mailman/listinfo/devel
>
>
>
>
> -- 
>
> ______________________________
>
> <http://www.tallertechnologies.com>
>
> *
> *
>
> Marcos Díaz
>
> Software Engineer
>
> *
> *
>
> San Lorenzo 47, 3rd Floor, Office 5
>

> Córdoba, Argentina
>
> *
> *
>
> Phone:+54 351 4217888 / +54 351 4218211/ +54 351 7617452
>
> Skype:markdiaz22
>
>

-- 
Joel Sherrill, Ph.D.             Director of Research & Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
Support Available                (256) 722-9985

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141106/427bb926/attachment-0002.html>


More information about the devel mailing list