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