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.casa...@tallertechnologies.com > <mailto:federico.casa...@tallertechnologies.com>> wrote: > > Hi, > > On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill > <joel.sherr...@oarcorp.com <mailto:joel.sherr...@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@rtems.org > <mailto:devel@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@rtems.org > <mailto:devel@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.sherr...@oarcorp.com <mailto:joel.sherr...@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@rtems.org <mailto:devel@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.sherr...@oarcorp.com On-Line Applications Research Ask me about RTEMS: a free RTOS Huntsville AL 35805 Support Available (256) 722-9985
_______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
