<div dir="ltr">Hi,<br><div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Aug 26, 2014 at 3:46 PM, Joel Sherrill <span dir="ltr"><<a href="mailto:joel.sherrill@oarcorp.com" target="_blank">joel.sherrill@oarcorp.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
First. Thanks for the work and taking the time and effort to <br>
submit it.<br>
<br>
Specifics below, but the general answer is to submit all RTEMS<br>
changes as reviewable patches to <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>. We can<br>
then review them and get them merged. This will leave us<br>
with just the LWIP changes.<br>
<br>
Then we can review those and begin to work with that community<br>
to get them merged.<div class=""><br>
<br>
<br>
<div>On 8/26/2014 6:22 AM, Federico Casares
wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">Hi,<br>
<br>
In the past weeks we were working on porting the last LWIP
version to RTEMS for<br>
the LPC1768 microcontroller. Our main goal was to accomplish
this with the<br>
minimum number of changes for both projects. Fortunately, the
result was<br>
positive.<br>
<br>
Now, we are capable of providing to the community with this new
version of the<br>
RTEMS+LWIP port. In details:<br>
<br>
- RTEMS: last git revision = baa3c91ecb8a3b48ef387b938fcdb6
<div dir="ltr">e60b5bdc8a<br>
- LWIP: last git revision =
63038e03055183e3bc043711ada1de3bb907e989<br>
- LPC1768: based on MBED driver = <a href="https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP" target="_blank">https://github.com/mbedmicro/mbed/tree/master/libraries/net/eth/lwip-eth/arch/TARGET_NXP</a><br>
<br>
<br>
The list of changes follows:<br>
<br>
- RTEMS OS: No changes were needed here. Despite this we will
be posting a<br>
possible improvement in the newlib maillist soon. It consist
in adding the gcc<br>
function attribute "warn_unused_result" to the pthread_*_init
functions. As a<br>
result, developers will be warned about checking the return
value. NOTE: a<br>
common error here could be not checking the return value,
assuming a successful<br>
result, and trying to, for example, lock a mutex which init
function has<br>
returned ENOMEM. (We found this exact mistake in the current
LWIP OS layer<br>
implementation for Unix)<br>
<br>
</div>
</div>
</blockquote></div>
FWIW the gcc C++ library adapters for threading do not check the
results from<br>
those operations. This is an open sore spot for us. <br><div class="">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">- RTEMS LPC1768_MBED BSP: We added a new section
to the linker script, so we<br>
were able to put the LWIP and driver buffers in an exact
memory location (useful<br>
when working with DMA devices).<br>
<br>
</div>
</div>
</blockquote></div>
This sounds like a discrete patch to submit to <a href="mailto:devel@rtems.org" target="_blank">devel@rtems.org</a>.<div class=""><br></div></div></blockquote><div>Already sent. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">- RTEMS LPC1768_MBED Ethernet Driver: Based on an
existing driver from MBED, we<br>
ported it to RTEMS. NOTE: we will be creating our own driver
in the near future.<br>
<br>
</div>
</div>
</blockquote></div>
What is the license of these drivers?<div class=""><br></div></div></blockquote><div>GPLv2. Is this ok? <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">- LWIP: As mentioned previously, we needed to put
all LWIP buffers in DMA memory<br>
locations. Consequently, we added the "section" attribute to
LWIP ram_heap and<br>
memp_memory buffers. Furthermore, as this is a common strategy
in embedded<br>
devices with DMA, we made it generic and we will send these
changes to the LWIP<br>
project. Additionally, we will provide some minor adds/changes
to the lwip log<br>
system and statistics system.<br>
<br>
</div>
</div>
</blockquote></div>
OK. Those are obviously their's to review. :)<div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">- LWIP-contrib: Some of the changes/adds were:
fixing some issues related with<br>
posix initialization checks and allow set threads stack size.<br>
<br>
</div>
</div>
</blockquote></div>
What all specific to RTEMS was added? Do you want RTEMS Community
review<br>
on this?<br>
<br>
Is there a readme/howto to configure and use LWIP on RTEMS?<br>
<br>
It sounds like the port is largely BSP independent. Is this the
case?<div class=""><br></div></div></blockquote><div>See below. <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<div class="">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">- LWIP-test-app: A simple TCP echo server with
debugging functionality<br>
(rtems malloc statistics, rtems stack checker, lwip
statistics, driver<br>
statistics and registers dump) available.<br>
<br>
</div>
</div>
</blockquote></div>
Very cool! <br>
<br>
How large was the code/data/RAM use of the test application?<div class=""><br></div></div></blockquote><div>$ arm-rtems4.11-size -A -d o-optimize/lwip.exe<br><br>o-optimize/lwip.exe :<br>section size addr<br>
.start 840 0<br>.text 138000 840<br>.init 12 138840<br>.fini 12 138852<br>.rodata 14704 138864<br>.ARM.exidx 8 153568<br>
.eh_frame 4 153576<br>.init_array 4 153580<br>.fini_array 4 153584<br>.jcr 4 153588<br>.vector 1256 268435456<br>.data 1568 268436712<br>
.bss 8500 537378816<br>.work 29944 268438280<br>.eth 16312 537395200<br>.comment 109 0<br>.debug_aranges 15608 0<br>.debug_info 2525968 0<br>
.debug_abbrev 290957 0<br>.debug_line 897089 0<br>.debug_frame 34048 0<br>.debug_str 384335 0<br>.debug_loc 271111 0<br>.debug_ranges 19536 0<br>
.debug_macro 516169 0<br>.ARM.attributes 41 0<br>Total 5166143<br><br>(gdb) p Configuration<br>$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, <br>
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><div>, stack_allocate_hook = 0x15f61 <_Workspace_Allocate>, <br>
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>}</div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class="">
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr"><br>
As this new port is comprised of several patches and adds, it
would be great<br>
to have some advice in how to proceed. We can provide you with
the project as a<br>
whole or divided into independent patches. Also, we will need
to know which<br>
parts of the port are of RTEMS interest to be submitted.<br>
<br>
</div>
</div>
</blockquote></div>
RTEMS needs to nibble and digest the RTEMS stuff. That sounds pretty
easy.<br>
<br>
Then we can help or at least track and provide help getting the LWIP
port<br>
reviewed and merged by them.</div></blockquote><div><br><br><div>This project can be divided into 4 main parts:<br><br></div><div>1) RTEMS<br></div><div>2) LWIP<br></div><div>3) LWIP driver<br></div><div>4) User application<br>
</div><div><div><div style="display:inline-block"><div><span></span></div></div></div></div> <div>
<span lang="en"><span>Even though this project was developed for the LPC1768, almost all can be used for<br>other devices, </span></span><span lang="en"><span>with the obvious exception of the driver.<br>
<br></span></span></div><div><span lang="en"><span>As I told you, we tried to do this with minimum changes, and you will see that. The only<br></span></span></div><div><span lang="en"><span>pieces of code that are completely new (for RTEMS and LWIP) are the driver and the<br>
demo application.<br></span></span></div><div dir="ltr" style="zoom:1"><span lang="en"><span><br></span></span></div><div><span lang="en"><span>So, for each part:<br>
<br></span></span></div><div><span lang="en"><span>1) I will submit the change related to the linker script today, and we will be working in<br>the "GCC</span></span><span lang="en"><span> attributes" to send it to newlib.<br>
</span></span></div><div><span lang="en"><span>2) Should RTEMS have a version of LWIP in their building system? (maybe as an external<br>library) so anyone can use it for their projects?<br>
</span></span></div><div><span lang="en"><span>3) The driver is LWIP dependent and, as LWIP sources does not contains any kind of<br>driver,</span></span><span lang="en"><span> should we add this driver to the LPC1768 dsp implementation of RTEMS?.<br>
</span></span></div><div><span lang="en"><span>4) Should we add this application example to the list of RTEMS testsuites/samples?<br><br></span></span></div><span lang="en"><span>Regards.<div class=""><div id=":q3" class="" tabindex="0">
<img class="" src="https://ssl.gstatic.com/ui/v1/icons/mail/images/cleardot.gif"></div></div></span></span><br> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"><div class=""><br>
<blockquote type="cite">
<div dir="ltr">
<div dir="ltr">Regards.</div>
<br clear="all">
<br>
-- <br>
<div dir="ltr">
<div>
<div><span style="font-family:verdana,sans-serif"><a href="http://www.tallertechnologies.com" target="_blank"><img alt="http://www.tallertechnologies.com" src="http://www.tallertechnologies.com/templates/tallertechnologies/images/signature.png" height="78" width="200"></a><br>
Casares, Federico<br>
</span></div>
<span style="font-family:verdana,sans-serif">Sr. Software
Engineer<br>
</span></div>
<span style="font-family:verdana,sans-serif">Taller
Technologies Argentina<br>
<br>
<span style="font-size:8pt;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;vertical-align:baseline;background-color:transparent">San
Lorenzo 47, 3rd Floor, Office 5<br>
</span><span style="font-size:8pt;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;vertical-align:baseline;background-color:transparent">Córdoba,
Argentina</span></span><br>
</div>
</div>
</blockquote>
<br>
</div><span class=""><font color="#888888"><pre cols="72">--
Joel Sherrill, Ph.D. Director of Research & Development
<a href="mailto:joel.sherrill@OARcorp.com" target="_blank">joel.sherrill@OARcorp.com</a> On-Line Applications Research
Ask me about RTEMS: a free RTOS Huntsville AL 35805
Support Available (256) 722-9985</pre>
</font></span></div>
</blockquote></div><br><br clear="all"><br>-- <br><div dir="ltr"><div><div><span style="font-family:verdana,sans-serif"><a href="http://www.tallertechnologies.com" target="_blank"><img alt="http://www.tallertechnologies.com" src="http://www.tallertechnologies.com/templates/tallertechnologies/images/signature.png" height="78" width="200"></a><br>
Casares, Federico<br></span></div><span style="font-family:verdana,sans-serif">Sr. Software Engineer<br></span></div><span style="font-family:verdana,sans-serif">Taller Technologies Argentina<br><br><span style="font-size:8pt;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;vertical-align:baseline;background-color:transparent">San Lorenzo 47, 3rd Floor, Office 5<br>
</span><span style="font-size:8pt;color:rgb(0,0,0);font-weight:normal;font-style:normal;text-decoration:none;vertical-align:baseline;background-color:transparent">Córdoba, Argentina</span></span><br></div>
</div></div></div>