RTEMS+LWIP for LPC1768 BSP
Marcos Díaz
marcos.diaz at tallertechnologies.com
Tue Nov 4 21:01:44 UTC 2014
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
configuration of lwip options and ip address options
use of socket api and integrating it to the libraries used in RTEMS.
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20141104/945fcded/attachment-0001.html>
More information about the devel
mailing list