Hi Pavel, On Thu, Jun 2, 2022 at 12:09 AM Pavel Pisa <ppisa4li...@pikron.com> wrote: > > Dear Vijay, > > On Thursday 02 of June 2022 05:56:56 Vijay Kumar Banerjee wrote: > > I have pushed this patch and I would like to add a note regarding that. > > thanks for the work and time. > No problem. I hope we can soon promote the rtems-lwip repository to the top-level.
> > This patch started interesting discussions about the possible ways to > > organize code from multiple sources. Pavel also raised an issue with > > the directory name "uLan". Since the repository is still in a personal > > area and still in the development stage, we can make rapid changes to > > the repository. We will change the directory name from uLan to > > something that's more suitable, > > please no uLAN it is RS-485 protocol. Yes it has and reuses our sysless > firware base project and uses OOMK build system which we use > for build of GNU/Linux, sysless, RTEMS, NuttX and even Windows > applications. Because I used our port of LwIP which uses OMK > build to test it in RTEMS I have named it lwip-omk and because > we use the code in our instruments firmware which use OMK build, > sysless and often uLAN protocol it ended in the repo under > uLAN project. > > https://sourceforge.net/p/ulan/lwip-omk/ci/omk-devel/tree/ > > But using this project name in the case where > OMK buid system is unwanted, there is nor RS-485 connection > and no use of other libraries and bare metal support from > that PiKRON project is so misleading, that I have to insist > to not use uLAN label... > > I suggest to have only ports directory at the rtems-lwip > toplevel. We should go through the process to relicense > all (where we are authors or where we can contact author) > to RTEMS mainline acceptable licence. If there is some problematic > driver then it stays in > > ports/driver/driver_name > > directory so it will be separated and license precisely defined > in that directory. > This is a good idea, and I totally agree with this approach. The directories can be named with the target name, and the information of the source can be included in a file there. > I still see in the driers base only our own tms570_emac. > So what is the plan for integrating others? > I realized that a few patches are in my local machine that never made it to the repository. Kinsey is working on another port. We will have at least two more ports soon. > It would be great to have there at least two working > ports because then it will be seen how to select them > on the build system level. > > Thanks for updating project documentation > > https://devel.rtems.org/wiki/Packages/LWIP > > There is another task to solve. In the OMK build, > there has been made possible to configure the most > of the LwIP options from the project top level > config.omk and config.target. It should be considered, > how buffers size, count and many other featires will > be configured in actual RSB build. Problem is that > LwIP on targets with little memory (it worked on > 256 kB TMS570LS3137) and on the other hand configuration > for some bigger systems as is Gaisler GR740 or somethink > NOEL-V based can be significantly different when > megabytes of RAM can be used. > The waf scripts can be extended in the way similar to top level rtems-littlevgl that provides a default header file with config info, which get rewritten by the script based on manual configurations. https://git.rtems.org/packages/rtems-littlevgl/ > By the way, I am presenting at > > 9th International Workshop on Analogue and Mixed-Signal > Integrated Circuits for Space Applications > https://indico.esa.int/event/388/ > Nice! > and I have met there people from TTTech > and they can have interrest to try RTEMS > even on their TTEthernet space ASIC > internal Leon 2 core. But it is memory > constrained environment so for TCP/IP non-real time > traffic they most probably cannot use BSD stack, > so LwIP + RTEMS can be the option there. > This can be a nice project. > But it is necessary to put project into some > reusable shape. Unfortunately I do not have > time to work on it some intensive way now > and I do not know RSB stuff enough. > Handling the config will be the challenge, but a plain vanilla rtems-lwip can be built using similar RSB script used for libbsd. > On the other hand, if they express real interest, > I can try, if I am able attract some students > from our universitywho can work on the project. > I invest a lot to pass knowledge for their serious > work in this area. > > By the way, we have switched our Computer Architectures > course to RISC-V in this run > > https://cw.fel.cvut.cz/wiki/courses/b35apo/en/start > > including simulator > > https://github.com/cvut/qtrvsim > > and public recording (even English, sorry Czenglish) > > https://www.youtube.com/playlist?list=PLQL6z4JeTTQnTrML7HgagbjdpCtvdyu0M Thanks for making the lecture pdfs public and uploading the videos on youtube! Best regards, Vijay > > Best wishes, > > Pavel Pisa > > ================================================== > PiKRON s.r.o. Phone/Fax: +420 284684676 > Kankovskeho 1235 Phone: +420 234697622 > 182 00 Praha 8 WWW: http://www.pikron.com/ > Czech Republic e-mail: pik...@pikron.com > ================================================== _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
