On Mon, Feb 1, 2021 at 5:16 PM Mr. Andrei Chichak <[email protected]> wrote:
> Can you point me at Sebastian’s driver? I haven’t been able to find it in > the repo. > Here's the trick. Look in rtemsbsd/include/bsp/nexus-devices.h and search for the header guard from your BSP. It references an stmac driver which find tells me is ./rtemsbsd/sys/dev/stmac/if_stmac.c. I am sure the directory has other files. That's the magic path. Takes some getting used to. --joel > > A > > On 2021-February-01, at 16:05, Joel Sherrill <[email protected]> wrote: > > > > On Mon, Feb 1, 2021 at 4:54 PM Mr. Andrei Chichak <[email protected]> > wrote: > >> Oh, crap, I’m off by 3 orders of magnitude, I’ve got 512KB. >> > > That's an LWIP candidate. :) > > But Sebastian did a driver for libbsd for the H7 series. If you have more > memory > or can attach external RAM, that's an option. > > >> Bother, I need a nap already. >> >> A >> >> On 2021-February-01, at 15:35, Joel Sherrill <[email protected]> wrote: >> >> >> >> On Mon, Feb 1, 2021 at 4:25 PM Andrei Chichak <[email protected]> wrote: >> >>> any guidance choosing between “Legacy Stack” and libbsd? >>> >> >> This one is easy. Please please please please do NOT choose the legacy >> stack. :) >> >> The legacy stack should only be used on projects that are using it and >> those >> are encouraged to move along to libbsd or lwip or new hardware. We have >> no >> plans to eliminate the legacy stack from the world. But as Gedare said, >> we want >> to move it to a separate repository. If someone cares, then it gets a >> build system >> and can be used with a strong discouragement. >> >> It is 20+ years old now and IPV4 only. Do the math. :) >> >> >>> >>> I’ve got a 512MB of RAM processor, so I expect that I’ll have lots left >>> over. But that is TBD. >>> >> >> 512MB is still huge in RTEMS terms. That won't be a problem for libbsd at >> all. It is when you >> start considering targets with < 16MB that we have concerns. I suspect >> that number is <4MB >> but the original BSP for the legacy stack only had 1MB for code and data >> space. It is clear >> some boards that could run the legacy stack will not be capable of >> running libbsd but we >> don't have a hard cutoff yet. >> >> --joel >> >>> >>> A >>> >>> On 2021-February-01, at 15:21, Joel Sherrill <[email protected]> wrote: >>> >>> >>> >>> On Mon, Feb 1, 2021 at 4:03 PM Gedare Bloom <[email protected]> wrote: >>> >>>> >>>> >>>> On Mon, Feb 1, 2021 at 2:42 PM Chris Johns <[email protected]> wrote: >>>> >>>>> On 2/2/21 8:32 am, Mr. Andrei Chichak wrote: >>>>> > Is there any advantage to using bsd networking over LWiP, or vice >>>>> versa? >>>>> >>>>> They are different stacks with different feature sets and different >>>>> hardware >>>>> resource demands. I am not familiar with the features of LwIP so I am >>>>> not the >>>>> best person to compare them. >>>>> >>>>> The BSD stack has most of the features you get with FreeBSD. It has >>>>> IPv4, IPv6, >>>>> IPsec, VLAN, bridging, dhcp, openssl, lots of routing alternatives, >>>>> packet >>>>> filtering and more. It has a range of useful commands including >>>>> tcpdump. >>>>> >>>>> The BSD based system provides a solid base to solve a range of >>>>> networking issues >>>>> your RTEMS device may encounter at the system level and not at the low >>>>> level >>>>> programming level. >>>>> >>>>> The BSD stack uses a lot more resources to do all this and LwIP may be >>>>> a prefect >>>>> fit. I welcome RTEMS being able to support a range of networking >>>>> solutions. >>>>> >>>>> >>>> I have a student (Vijay) working on refactoring libnetworking out of >>>> RTEMS, and will be testing ability to compile legacy vs libbsd. If the lwip >>>> build is demonstrated and clear, I can have him also look at bringing that >>>> into the fold. This is in line with https://devel.rtems.org/ticket/3850 >>>> >>> >>> One thing to be aware of is that all the POSIX networking header files >>> for RTEMS are in newlib and always present. I had to address this and lwip >>> when we did Deos+RTEMS. Deos uses lwip as their native stack running in a >>> partition and other partitions use a client to get to it. The lwip >>> constants had values that were not the same as the RTEMS BSD headers for >>> POSIX defines. There were also some places where the structure definitions >>> did not align. I had to write a bit of mapping in the client. When lwip >>> works at all, it would be awesome to have a way for it to ignore their own >>> minimal POSIX API files and build against ours. >>> >>> This would be similar to how the newlib headers define a very complete >>> POSIX API set but each target OS may only support a subset of it. >>> >>> As it is, I wonder if there is a conflict between the RTEMS newlib >>> network .h files and those provided by lwip which could cause issues. >>> >>> >>>> >>>> We have no certain timeline yet, but it is now work-in-progress. We >>>> will bring to devel when progress is made. If we do lwIP too, we will aim >>>> to do a performance analysis with real hardware, so that we can hopefully >>>> provide evidence to help these kind of questions. >>>> >>>> -Gedare >>>> >>>> Chris >>>>> >>>> _______________________________________________ >>>> users mailing list >>>> [email protected] >>>> http://lists.rtems.org/mailman/listinfo/users >>> >>> _______________________________________________ >>> users mailing list >>> [email protected] >>> http://lists.rtems.org/mailman/listinfo/users >>> >>> >>> --------------------- >>> Andrei Chichak >>> 4024-120 STREET >>> EDMONTON, ALBERTA >>> T6J 1X8 >>> CANADA >>> >>> >>> Phone: 780-434-6266 >>> Skype: andrei.chichak >>> >>> >>> >>> >>> >>> >>> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.rtems.org/mailman/listinfo/users >> >> >> >> _______________________________________________ >> users mailing list >> [email protected] >> http://lists.rtems.org/mailman/listinfo/users > > >
_______________________________________________ users mailing list [email protected] http://lists.rtems.org/mailman/listinfo/users
