RTEMS+LWIP for LPC1768 BSP
Marcos Díaz
marcos.diaz at tallertechnologies.com
Fri Nov 7 13:50:51 UTC 2014
On Thu, Nov 6, 2014 at 6:26 PM, Joel Sherrill <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.
>
> 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.casares at tallertechnologies.com> wrote:
>
>> Hi,
>>
>> On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill <
>> 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. 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.
>>>
>>> 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 "GCC attributes" 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.
>>>
>>>
>>> --
>>> [image: 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 & Developmentjoel.sherrill at OARcorp.com On-Line Applications Research
>>> Ask me about RTEMS: a free RTOS Huntsville AL 35805
>>> Support Available (256) 722-9985
>>>
>>>
>>
>>
>> --
>> [image: 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
>> 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 & Developmentjoel.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>
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141107/835c65f9/attachment-0001.html>
More information about the devel
mailing list