Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project
(Adding devel back in the CC) On Wed, Apr 24, 2024 at 1:34 AM Purva Yeshi wrote: > Please feel free to call me Vijay :) > > Sure. > > That's great! You might be able to relate some of the documentation to the >> riscv BSP code in the repository. > > Yes, and I also added examples related to riscv > > Nice > Have you set up any public repository that we might be able to follow and >> provide early feedback? It is okay to have work-in-progress commits in your >> repository. > > Yes I forked rtems-docs and commit those changes > Here is the link: > https://github.com/purviyeshi/rtems-docs/blob/master/bsp-howto/target_dependant_files.rst > > I had a quick look at the document. Did the content under "peripheral dependant" and "board dependant" get switched? Based on the lines preceding your additions. On Wed, 24 Apr 2024 at 03:26, Vijay Kumar Banerjee wrote: > >> Hi Purva, >> >> On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi >> wrote: >> >>> Hello Sir, >>> >> >> Please feel free to call me Vijay :) >> >> >>> >>> Up until now, I have been studying the BSP driver documentation from >>> https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a >>> good understanding of why and how target-dependent files are written. >>> Additionally, I am currently working on how the console and clock driver >>> are written. >>> >>> That's great! You might be able to relate some of the documentation to >> the riscv BSP code in the repository. >> >> >>> Furthermore, I have been modifying the target-dependent files by adding >>> more examples to make them more understandable for new users. >>> >> >> Have you set up any public repository that we might be able to follow and >> provide early feedback? It is okay to have work-in-progress commits in your >> repository. >> >> >> Best regards, >> Vijay >> >>> >>> On Fri, 5 Apr 2024 at 21:36, Purva Yeshi >>> wrote: >>> >>>> Thank you for all the resources. >>>> >>>> Yes, I go through the documentation and the codebase, and I'll try to >>>> send patches >>>> Okay, got the point about mailing list and github >>>> >>>> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee >>>> wrote: >>>> >>>>> Hi Purva, >>>>> >>>>> >>>>> >>>>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi >>>>> wrote: >>>>> >>>>>> Hello, >>>>>> >>>>>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire >>>>>> based Beagle" for GSoC 2024. I proposed a project to create a BSP for the >>>>>> Beagle-V fire board from scratch. The primary objective of the project is >>>>>> to run a "Hello World" code and a ticker on the board. After that, I will >>>>>> focus on developing support for other devices such as Ethernet and U54 >>>>>> MMU. >>>>>> >>>>>> Great! Thanks for completing the proposal and submitting it on the >>>>> portal. >>>>> >>>>> >>>>>> During this waiting period for acceptance, I want to familiarize >>>>>> myself with the codebase of existing supported components of other RISC-V >>>>>> BSP variants. As part of my preparation, I have already built an RTEMS >>>>>> development environment and successfully completed the RTEMS Hello World >>>>>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant. >>>>>> >>>>>> >>>>> Since you already have a working RTEMS environment, it would be a >>>>> great idea to start looking at the source code organization of riscv bsps >>>>> ( >>>>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful >>>>> to find some smaller issues (maybe in the documentation) and try to send >>>>> patches for that. Submitting patches for smaller issues is a great idea to >>>>> become familiar with the code contribution process. The documentation for >>>>> riscv bsps can be found at >>>>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html >>>>> >>>>> You can also utilize this time to read up on the Beagle-V
Re: RTEMS 6 branching
On Tue, Apr 23, 2024 at 1:02 PM Joel Sherrill wrote: > > > On Tue, Apr 23, 2024, 12:56 PM Sebastian Huber < > sebastian.hu...@embedded-brains.de> wrote: > >> - Am 21. Apr 2024 um 3:00 schrieb Chris Johns chr...@rtems.org: >> >> > Hi, >> > >> > There has been some discussion about when we will branch and it is >> timely we >> > discuss this. This is my input. :) >> > >> > While I create the releases I am not solely responsible for milestone >> dates or >> > thresholds for a release. >> > >> > Please test the RC snaphots on our ftp server. Saying you have is as >> important >> > as reporting issues. >> > >> > 1. Are all the things need for the release resolved? Tickets reviewed? >> >> It would be nice to have the interrupt get/set priority API in RTEMS 6. >> The Cortex-M floating point issue is not yet fixed in the RTEMS master. >> > > There should be time to get it in. The Gitlab transition needs to be > complete before the branch is cut. > >> >> > >> > 2. The tickets are now in GitLab and locked down in Trac so how does >> that work >> > if we make a release now? I do not think it does. >> > >> > 3. GitLab is going to happen soon so do we take this moment in time and >> make 6 >> > with GitLab and learn what we need to do easing dot releases that >> always follow? >> > If we do not we may end up with 6.1 and then 6.2 that has differences. >> >> We should definitely wait with the release after the Gitlab migration is >> done and some basic CI is running. >> > > I don't think holding a release for CI is needed. We have the same basic > quality and testing we have now. > > Requiring more work and improvements just moves the release bar. > > That said, we do need to get some CI processes in place. Hopefully between > 6.1 and 6.2, we will have at least one or two BSPs required to build. > >> >> > >> > 4. GitLab breaks the release scripts for the release notes (ChangeLog). >> Amar and >> > I have discussed a few options but we are yet to test and settle on >> anything. As >> > is the case with these things easy is often is a series of small things >> that >> > take time to get right. >> > >> > 5. Have the docs been reviewed for RTEMS 5 vs RTEMS 6 changes? Are they >> updated >> > for a separated legacy network stack, net services and waf building? >> > > Ryan and Ray worked on the autoconf to waf documentation changes a couple > of years ago. > > I have no idea what impact the separated Network stacks have on the > documentation. > The legacy networking docs are separated now with instructions on how to build them using waf: https://docs.rtems.org/branches/master/legacy-networking/index.html We might need to mention in the user manual that there is no default networking stack anymore and the user needs to build the network stack separately. > > > 6. I have a few small patches to push and then an update to the RSB to >> pick >> > those changes up before I can create RC4. >> >> I recently checked in a fix for powerpc and the AArch64 multilib changes >> for Cortex-A53 in GCC 13. To pick this up, the GCC commit needs to be >> updated. Maybe we should even wait for the GCC 13.3 release. >> > > I asked about a gcc 13.3 release and we should not wait. They intend to do > a 14 release before returning to 13.3. We should plan to do 6.1 with a GCC > 13 branch hash and probably plan to swap that out with a 13.3 tarball when > it's released. > > We are good at imposing more requirements. :) > > > > >> > >> > >> > Thanks >> > Chris >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel >> >> -- >> embedded brains GmbH & Co. KG >> Herr Sebastian HUBER >> Dornierstr. 4 >> 82178 Puchheim >> Germany >> email: sebastian.hu...@embedded-brains.de >> phone: +49-89-18 94 741 - 16 >> fax: +49-89-18 94 741 - 08 >> >> Registergericht: Amtsgericht München >> Registernummer: HRB 157899 >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler >> Unsere Datenschutzerklärung finden Sie hier: >> https://embedded-brains.de/datenschutzerklaerung/ >> ___ >> devel mailing list >> devel@rtems.org >> http://lists.rtems.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project
Hi Purva, On Tue, Apr 23, 2024 at 3:18 PM Purva Yeshi wrote: > Hello Sir, > Please feel free to call me Vijay :) > > Up until now, I have been studying the BSP driver documentation from > https://docs.rtems.org/branches/master/bsp-howto/ . I have gained a good > understanding of why and how target-dependent files are written. > Additionally, I am currently working on how the console and clock driver > are written. > > That's great! You might be able to relate some of the documentation to the riscv BSP code in the repository. > Furthermore, I have been modifying the target-dependent files by adding > more examples to make them more understandable for new users. > Have you set up any public repository that we might be able to follow and provide early feedback? It is okay to have work-in-progress commits in your repository. Best regards, Vijay > > On Fri, 5 Apr 2024 at 21:36, Purva Yeshi wrote: > >> Thank you for all the resources. >> >> Yes, I go through the documentation and the codebase, and I'll try to >> send patches >> Okay, got the point about mailing list and github >> >> On Fri, 5 Apr 2024 at 02:21, Vijay Kumar Banerjee >> wrote: >> >>> Hi Purva, >>> >>> >>> >>> On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi >>> wrote: >>> >>>> Hello, >>>> >>>> I am Purva Yeshi, I applied for the project "Add BSP for Polarfire >>>> based Beagle" for GSoC 2024. I proposed a project to create a BSP for the >>>> Beagle-V fire board from scratch. The primary objective of the project is >>>> to run a "Hello World" code and a ticker on the board. After that, I will >>>> focus on developing support for other devices such as Ethernet and U54 MMU. >>>> >>>> Great! Thanks for completing the proposal and submitting it on the >>> portal. >>> >>> >>>> During this waiting period for acceptance, I want to familiarize myself >>>> with the codebase of existing supported components of other RISC-V BSP >>>> variants. As part of my preparation, I have already built an RTEMS >>>> development environment and successfully completed the RTEMS Hello World >>>> project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant. >>>> >>>> >>> Since you already have a working RTEMS environment, it would be a great >>> idea to start looking at the source code organization of riscv bsps ( >>> https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful >>> to find some smaller issues (maybe in the documentation) and try to send >>> patches for that. Submitting patches for smaller issues is a great idea to >>> become familiar with the code contribution process. The documentation for >>> riscv bsps can be found at >>> https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html >>> >>> You can also utilize this time to read up on the Beagle-V fire >>> documentation and the prior FreeBSD efforts to support that board. >>> >>> Could you please provide guidance on this. Additionally, is there any >>>> specific task or area you suggest I focus on during this period for the >>>> project? >>>> >>> >>> Feel free to ask about anything you find interesting (or confusing) >>> while going through the source code and the documentation. Especially with >>> the documentation, if something confuses you it likely confuses other >>> people too, it can be a place to make a great contribution! >>> >>> The mailing list is the best place to discuss longer questions, and the >>> discord channel is better for quick help from people who are signed in. The >>> discord channel has a subset of the RTEMS developers on it, the mailing >>> list has a wider audience. >>> >>> >>> Good luck with the GSoC application! >>> >>> Best regards, >>> Vijay >>> >>> ___ >>> >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Introduction and preparation for the "Add BSP for Polarfire based Beagle" Project
Hi Purva, On Thu, Apr 4, 2024 at 6:05 AM Purva Yeshi wrote: > Hello, > > I am Purva Yeshi, I applied for the project "Add BSP for Polarfire based > Beagle" for GSoC 2024. I proposed a project to create a BSP for the > Beagle-V fire board from scratch. The primary objective of the project is > to run a "Hello World" code and a ticker on the board. After that, I will > focus on developing support for other devices such as Ethernet and U54 MMU. > > Great! Thanks for completing the proposal and submitting it on the portal. > During this waiting period for acceptance, I want to familiarize myself > with the codebase of existing supported components of other RISC-V BSP > variants. As part of my preparation, I have already built an RTEMS > development environment and successfully completed the RTEMS Hello World > project on the Qemu spike simulator for the riscv/rv64imafdc BSP variant. > > Since you already have a working RTEMS environment, it would be a great idea to start looking at the source code organization of riscv bsps ( https://git.rtems.org/rtems/tree/bsps/risc). It would also be helpful to find some smaller issues (maybe in the documentation) and try to send patches for that. Submitting patches for smaller issues is a great idea to become familiar with the code contribution process. The documentation for riscv bsps can be found at https://docs.rtems.org/branches/master/user/bsps/bsps-riscv.html You can also utilize this time to read up on the Beagle-V fire documentation and the prior FreeBSD efforts to support that board. Could you please provide guidance on this. Additionally, is there any > specific task or area you suggest I focus on during this period for the > project? > Feel free to ask about anything you find interesting (or confusing) while going through the source code and the documentation. Especially with the documentation, if something confuses you it likely confuses other people too, it can be a place to make a great contribution! The mailing list is the best place to discuss longer questions, and the discord channel is better for quick help from people who are signed in. The discord channel has a subset of the RTEMS developers on it, the mailing list has a wider audience. Good luck with the GSoC application! Best regards, Vijay ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build
On Wed, Aug 9, 2023 at 8:04 PM Chris Johns wrote:
>
> On 10/8/2023 2:41 am, Joel Sherrill wrote:
> > Reading the EPICS discussion, I wonder if this should be added for all
> > motorola_powerpc BSP variants.
> >
> > Gedare/Chris/anyone with another board in the family? What do you think?
>
> Michael asked if the setting is present when building libc, libm etc in the
> EPICS core devs meeting today and I could not answer the question?
I just built the tools for powerpc and it looks like libc, libm are
not built with the -mstrict-align flag.
> Is it
> exported in the .pc or Makefile.inc flags?
>
This flag is exported in ${RTEMS_BSP}.cfg file in RTEMS, which gets
included by EPICS though CONFIG.Common.RTEMS:
https://github.com/epics-base/epics-base/blob/7.0/configure/os/CONFIG.Common.RTEMS#L38
The `RTEMS_CUSTOM` variable is defined in Makefile.inc, and it points
to the ${RTEMS_BSP}.cfg file
> Chris
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build
On Wed, Aug 9, 2023 at 3:26 PM Vijay Kumar Banerjee wrote: > > On Wed, Aug 9, 2023 at 3:05 PM Joel Sherrill wrote: > > > > Vijay.. go ahead and push this if you don't mind. > > > Sure, I will push this. Pushed. Thanks. > > > I was just wondering if we could make a blanket statement that all > > motorola_powerpc variants need this flag. > > I do not have a test case other than the EPICS error. At least 2 BSPs > (2100, 2700/2307) in motorola_powerpc need this, and except mcp750 all > other BSPs in motorola_powerpc seem to have it in the spec. It is > likely that all motorola_powerpc variants need this. > > > > > On Wed, Aug 9, 2023 at 12:01 PM Vijay Kumar Banerjee > > wrote: > >> > >> On Wed, Aug 9, 2023 at 11:41 AM Joel Sherrill wrote: > >> > > >> > Reading the EPICS discussion, I wonder if this should be added for all > >> > motorola_powerpc BSP variants. > >> > > >> MVME2700 and the qemu variants already add it separately > >> https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/motorola_powerpc/abi.yml#n24 > >> > >> > Gedare/Chris/anyone with another board in the family? What do you think? > >> > >> 2700 works for me, and it already has the flag added. > >> > >> > > >> > --joel > >> > > >> > On Wed, Aug 9, 2023 at 11:14 AM Uchenna Ezeobi > >> > wrote: > >> >> > >> >> On Wed, Aug 9, 2023 at 9:22 AM Joel Sherrill wrote: > >> >> > > >> >> > I'm ok with this if there is a known case of an alignment exception > >> >> > that causes this. > >> >> > > >> >> We were getting the error from the > >> >> https://github.com/epics-base/epics-base/issues/29 while trying to > >> >> build EPICS on RTEMS-MVME2100, doing this fixed the error. > >> >> > >> >> > We didn't want to force it into every PowerPC BSP. > >> >> > > >> >> > Do you have a case that failed and was resolved by adding this? > >> >> > > >> >> > On Wed, Aug 9, 2023 at 7:36 AM Uchenna Ezeobi > >> >> > wrote: > >> >> >> > >> >> >> Update #3767 > >> >> >> --- > >> >> >> spec/build/bsps/powerpc/motorola_powerpc/abi.yml | 4 > >> >> >> 1 file changed, 4 insertions(+) > >> >> >> > >> >> >> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml > >> >> >> b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml > >> >> >> index 6734e9babf..2438c30f1d 100644 > >> >> >> --- a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml > >> >> >> +++ b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml > >> >> >> @@ -17,6 +17,10 @@ default: > >> >> >>- -mcpu=powerpc > >> >> >>- -mmultiple > >> >> >>- -mstrict-align > >> >> >> +- enabled-by: [powerpc/mvme2100] > >> >> >> + value: > >> >> >> + - -mcpu=603e > >> >> >> + - -mstrict-align > >> >> >> - enabled-by: [powerpc/mvme2307, powerpc/mvme2700] > >> >> >>value: > >> >> >>- -mcpu=604 > >> >> >> -- > >> >> >> 2.39.3 > >> >> >> > >> >> >> ___ > >> >> >> devel mailing list > >> >> >> devel@rtems.org > >> >> >> http://lists.rtems.org/mailman/listinfo/devel > >> > > >> > ___ > >> > devel mailing list > >> > devel@rtems.org > >> > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build
On Wed, Aug 9, 2023 at 3:05 PM Joel Sherrill wrote: > > Vijay.. go ahead and push this if you don't mind. > Sure, I will push this. > I was just wondering if we could make a blanket statement that all > motorola_powerpc variants need this flag. I do not have a test case other than the EPICS error. At least 2 BSPs (2100, 2700/2307) in motorola_powerpc need this, and except mcp750 all other BSPs in motorola_powerpc seem to have it in the spec. It is likely that all motorola_powerpc variants need this. > > On Wed, Aug 9, 2023 at 12:01 PM Vijay Kumar Banerjee wrote: >> >> On Wed, Aug 9, 2023 at 11:41 AM Joel Sherrill wrote: >> > >> > Reading the EPICS discussion, I wonder if this should be added for all >> > motorola_powerpc BSP variants. >> > >> MVME2700 and the qemu variants already add it separately >> https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/motorola_powerpc/abi.yml#n24 >> >> > Gedare/Chris/anyone with another board in the family? What do you think? >> >> 2700 works for me, and it already has the flag added. >> >> > >> > --joel >> > >> > On Wed, Aug 9, 2023 at 11:14 AM Uchenna Ezeobi >> > wrote: >> >> >> >> On Wed, Aug 9, 2023 at 9:22 AM Joel Sherrill wrote: >> >> > >> >> > I'm ok with this if there is a known case of an alignment exception >> >> > that causes this. >> >> > >> >> We were getting the error from the >> >> https://github.com/epics-base/epics-base/issues/29 while trying to >> >> build EPICS on RTEMS-MVME2100, doing this fixed the error. >> >> >> >> > We didn't want to force it into every PowerPC BSP. >> >> > >> >> > Do you have a case that failed and was resolved by adding this? >> >> > >> >> > On Wed, Aug 9, 2023 at 7:36 AM Uchenna Ezeobi >> >> > wrote: >> >> >> >> >> >> Update #3767 >> >> >> --- >> >> >> spec/build/bsps/powerpc/motorola_powerpc/abi.yml | 4 >> >> >> 1 file changed, 4 insertions(+) >> >> >> >> >> >> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> >> b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> >> index 6734e9babf..2438c30f1d 100644 >> >> >> --- a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> >> +++ b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> >> @@ -17,6 +17,10 @@ default: >> >> >>- -mcpu=powerpc >> >> >>- -mmultiple >> >> >>- -mstrict-align >> >> >> +- enabled-by: [powerpc/mvme2100] >> >> >> + value: >> >> >> + - -mcpu=603e >> >> >> + - -mstrict-align >> >> >> - enabled-by: [powerpc/mvme2307, powerpc/mvme2700] >> >> >>value: >> >> >>- -mcpu=604 >> >> >> -- >> >> >> 2.39.3 >> >> >> >> >> >> ___ >> >> >> devel mailing list >> >> >> devel@rtems.org >> >> >> http://lists.rtems.org/mailman/listinfo/devel >> > >> > ___ >> > devel mailing list >> > devel@rtems.org >> > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] spec: Add -mstrict-align to mvme2100 default build
On Wed, Aug 9, 2023 at 11:41 AM Joel Sherrill wrote: > > Reading the EPICS discussion, I wonder if this should be added for all > motorola_powerpc BSP variants. > MVME2700 and the qemu variants already add it separately https://git.rtems.org/rtems/tree/spec/build/bsps/powerpc/motorola_powerpc/abi.yml#n24 > Gedare/Chris/anyone with another board in the family? What do you think? 2700 works for me, and it already has the flag added. > > --joel > > On Wed, Aug 9, 2023 at 11:14 AM Uchenna Ezeobi > wrote: >> >> On Wed, Aug 9, 2023 at 9:22 AM Joel Sherrill wrote: >> > >> > I'm ok with this if there is a known case of an alignment exception that >> > causes this. >> > >> We were getting the error from the >> https://github.com/epics-base/epics-base/issues/29 while trying to >> build EPICS on RTEMS-MVME2100, doing this fixed the error. >> >> > We didn't want to force it into every PowerPC BSP. >> > >> > Do you have a case that failed and was resolved by adding this? >> > >> > On Wed, Aug 9, 2023 at 7:36 AM Uchenna Ezeobi >> > wrote: >> >> >> >> Update #3767 >> >> --- >> >> spec/build/bsps/powerpc/motorola_powerpc/abi.yml | 4 >> >> 1 file changed, 4 insertions(+) >> >> >> >> diff --git a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> index 6734e9babf..2438c30f1d 100644 >> >> --- a/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> +++ b/spec/build/bsps/powerpc/motorola_powerpc/abi.yml >> >> @@ -17,6 +17,10 @@ default: >> >>- -mcpu=powerpc >> >>- -mmultiple >> >>- -mstrict-align >> >> +- enabled-by: [powerpc/mvme2100] >> >> + value: >> >> + - -mcpu=603e >> >> + - -mstrict-align >> >> - enabled-by: [powerpc/mvme2307, powerpc/mvme2700] >> >>value: >> >>- -mcpu=604 >> >> -- >> >> 2.39.3 >> >> >> >> ___ >> >> devel mailing list >> >> devel@rtems.org >> >> http://lists.rtems.org/mailman/listinfo/devel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] mvme3100: Add BSP fatal extension
On Tue, Aug 1, 2023, 15:30 Joel Sherrill wrote:
>
>
> On Tue, Aug 1, 2023 at 2:52 PM Vijay Kumar Banerjee
> wrote:
>
>>
>>
>> On Tue, Aug 1, 2023, 12:20 Joel Sherrill wrote:
>>
>>>
>>>
>>> On Tue, Aug 1, 2023, 11:41 AM Vijay Kumar Banerjee
>>> wrote:
>>>
>>>> ---
>>>> bsps/powerpc/mvme3100/start/bspclean.c| 25 +++
>>>> .../bsps/powerpc/mvme3100/bspmvme3100.yml | 1 +
>>>> 2 files changed, 26 insertions(+)
>>>> create mode 100644 bsps/powerpc/mvme3100/start/bspclean.c
>>>>
>>>> diff --git a/bsps/powerpc/mvme3100/start/bspclean.c
>>>> b/bsps/powerpc/mvme3100/start/bspclean.c
>>>> new file mode 100644
>>>> index 00..251d47a46d
>>>> --- /dev/null
>>>> +++ b/bsps/powerpc/mvme3100/start/bspclean.c
>>>> @@ -0,0 +1,25 @@
>>>>
>>>
>>> There is no copyright, licence, or Doxygen file header block.
>>>
>>> +#include
>>>> +#include
>>>> +#include
>>>> +
>>>> +void bsp_fatal_extension(
>>>> + rtems_fatal_source source,
>>>> + bool always_set_to_false,
>>>> + rtems_fatal_code error
>>>> +)
>>>> +{
>>>> + printk("fatal source: %s\n", rtems_fatal_source_text(source));
>>>> +
>>>> + if (source == RTEMS_FATAL_SOURCE_EXCEPTION) {
>>>> +rtems_exception_frame_print((const rtems_exception_frame *) error);
>>>> + }
>>>> +
>>>> + /* We can't go back to MotLoad since we blew it's memory area
>>>> + * and vectors. Just pull the reset line...
>>>> + */
>>>> + printk(
>>>> +"bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad
>>>> "
>>>> + "so I reset the card\n"
>>>> + );
>>>> + bsp_reset();
>>>> +}
>>>>
>>>
>>> What does Motorola PowerPC or the other similar bsps do?
>>>
>>> Can the behaviour be unified and shared?
>>>
>>
>> Thanks for the suggestion!
>> Motorola powerpc uses bspfatal-default.c from bsps/shared. It was not
>> working with mvme3100 because it added the bspreset-empty in the build.
>> Just removing the empty reset makes it work. This patch is no longer
>> needed. I'll send a smaller patch with this much neater solution using the
>> shared defaults.
>>
>
> Wow! Good to hear. Probably should check beatnik and the other mvme* ppc
> BSPs as well,
>
At least two bsps (mvme5500 and beatnik) has this issue. I will test on the
hardware and post patches for other boards too.
>
>>
>> Thanks!
>>
>
> No problem.
>
> --joel
>
>>
>>
>>> diff --git a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>>>> b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>>>> index 1667c1617a..dc04e4dd36 100644
>>>> --- a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>>>> +++ b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>>>> @@ -64,6 +64,7 @@ source:
>>>> - bsps/powerpc/mvme3100/pci/detect_host_bridge.c
>>>> - bsps/powerpc/mvme3100/rtc/todcfg.c
>>>> - bsps/powerpc/mvme3100/start/bspstart.c
>>>> +- bsps/powerpc/mvme3100/start/bspclean.c
>>>> - bsps/powerpc/mvme3100/start/misc.c
>>>> - bsps/powerpc/shared/btimer/btimer-ppc-dec.c
>>>> - bsps/powerpc/shared/cache/cache.c
>>>> --
>>>> 2.39.3
>>>>
>>>> ___
>>>> devel mailing list
>>>> devel@rtems.org
>>>> http://lists.rtems.org/mailman/listinfo/devel
>>>>
>>>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH RTEMS] spec: Remove empty reset from mvme3100
--- spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml | 1 - 1 file changed, 1 deletion(-) diff --git a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml index 1667c1617a..fbb85123f0 100644 --- a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml +++ b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml @@ -86,6 +86,5 @@ source: - bsps/shared/dev/getentropy/getentropy-cpucounter.c - bsps/shared/dev/rtc/rtc-support.c - bsps/shared/start/bspfatal-default.c -- bsps/shared/start/bspreset-empty.c - bsps/shared/start/gettargethash-default.c type: build -- 2.39.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RTEMS] mvme3100: Add BSP fatal extension
On Tue, Aug 1, 2023, 12:20 Joel Sherrill wrote:
>
>
> On Tue, Aug 1, 2023, 11:41 AM Vijay Kumar Banerjee
> wrote:
>
>> ---
>> bsps/powerpc/mvme3100/start/bspclean.c| 25 +++
>> .../bsps/powerpc/mvme3100/bspmvme3100.yml | 1 +
>> 2 files changed, 26 insertions(+)
>> create mode 100644 bsps/powerpc/mvme3100/start/bspclean.c
>>
>> diff --git a/bsps/powerpc/mvme3100/start/bspclean.c
>> b/bsps/powerpc/mvme3100/start/bspclean.c
>> new file mode 100644
>> index 00..251d47a46d
>> --- /dev/null
>> +++ b/bsps/powerpc/mvme3100/start/bspclean.c
>> @@ -0,0 +1,25 @@
>>
>
> There is no copyright, licence, or Doxygen file header block.
>
> +#include
>> +#include
>> +#include
>> +
>> +void bsp_fatal_extension(
>> + rtems_fatal_source source,
>> + bool always_set_to_false,
>> + rtems_fatal_code error
>> +)
>> +{
>> + printk("fatal source: %s\n", rtems_fatal_source_text(source));
>> +
>> + if (source == RTEMS_FATAL_SOURCE_EXCEPTION) {
>> +rtems_exception_frame_print((const rtems_exception_frame *) error);
>> + }
>> +
>> + /* We can't go back to MotLoad since we blew it's memory area
>> + * and vectors. Just pull the reset line...
>> + */
>> + printk(
>> +"bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad "
>> + "so I reset the card\n"
>> + );
>> + bsp_reset();
>> +}
>>
>
> What does Motorola PowerPC or the other similar bsps do?
>
> Can the behaviour be unified and shared?
>
Thanks for the suggestion!
Motorola powerpc uses bspfatal-default.c from bsps/shared. It was not
working with mvme3100 because it added the bspreset-empty in the build.
Just removing the empty reset makes it work. This patch is no longer
needed. I'll send a smaller patch with this much neater solution using the
shared defaults.
Thanks!
> diff --git a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>> b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>> index 1667c1617a..dc04e4dd36 100644
>> --- a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>> +++ b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
>> @@ -64,6 +64,7 @@ source:
>> - bsps/powerpc/mvme3100/pci/detect_host_bridge.c
>> - bsps/powerpc/mvme3100/rtc/todcfg.c
>> - bsps/powerpc/mvme3100/start/bspstart.c
>> +- bsps/powerpc/mvme3100/start/bspclean.c
>> - bsps/powerpc/mvme3100/start/misc.c
>> - bsps/powerpc/shared/btimer/btimer-ppc-dec.c
>> - bsps/powerpc/shared/cache/cache.c
>> --
>> 2.39.3
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH RTEMS] mvme3100: Add BSP fatal extension
---
bsps/powerpc/mvme3100/start/bspclean.c| 25 +++
.../bsps/powerpc/mvme3100/bspmvme3100.yml | 1 +
2 files changed, 26 insertions(+)
create mode 100644 bsps/powerpc/mvme3100/start/bspclean.c
diff --git a/bsps/powerpc/mvme3100/start/bspclean.c
b/bsps/powerpc/mvme3100/start/bspclean.c
new file mode 100644
index 00..251d47a46d
--- /dev/null
+++ b/bsps/powerpc/mvme3100/start/bspclean.c
@@ -0,0 +1,25 @@
+#include
+#include
+#include
+
+void bsp_fatal_extension(
+ rtems_fatal_source source,
+ bool always_set_to_false,
+ rtems_fatal_code error
+)
+{
+ printk("fatal source: %s\n", rtems_fatal_source_text(source));
+
+ if (source == RTEMS_FATAL_SOURCE_EXCEPTION) {
+rtems_exception_frame_print((const rtems_exception_frame *) error);
+ }
+
+ /* We can't go back to MotLoad since we blew it's memory area
+ * and vectors. Just pull the reset line...
+ */
+ printk(
+"bsp_fatal_extension(): RTEMS terminated -- no way back to MotLoad "
+ "so I reset the card\n"
+ );
+ bsp_reset();
+}
diff --git a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
index 1667c1617a..dc04e4dd36 100644
--- a/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
+++ b/spec/build/bsps/powerpc/mvme3100/bspmvme3100.yml
@@ -64,6 +64,7 @@ source:
- bsps/powerpc/mvme3100/pci/detect_host_bridge.c
- bsps/powerpc/mvme3100/rtc/todcfg.c
- bsps/powerpc/mvme3100/start/bspstart.c
+- bsps/powerpc/mvme3100/start/bspclean.c
- bsps/powerpc/mvme3100/start/misc.c
- bsps/powerpc/shared/btimer/btimer-ppc-dec.c
- bsps/powerpc/shared/cache/cache.c
--
2.39.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 2/3] confdefs: Add configure macro for libi2c
On Tue, Jul 25, 2023 at 12:23 AM Sebastian Huber wrote: > > > > On 25.07.23 04:31, Vijay Kumar Banerjee wrote: > > On Mon, Jul 24, 2023 at 10:09 AM Sebastian Huber > > wrote: > >> On 20.07.23 03:10, Vijay Kumar Banerjee wrote: > >>> Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define > >> Do we really need this? What happens if an I2C device needs interrupts > >> during initialization? > >> > > the libi2c initialize calls rtems_io_register_driver, which requires > > `CONFIGURE_MAXIMUM_DRIVERS` defined from the application. In some > > BSPs, like mvme3100, libi2c is initialized at sysinit, causing the > > application to crash without the define. Adding this confdefs macro > > allows the user to add the libi2c if it is needed by the app, or omit > > it without crashing the system. In its current state, libi2c requires > > the BSP to handle registering the buses and drivers after > > initialization, the interrupt can be handled by the BSP I2C handler. > > Ok, maybe one option is to use IMFS_make_generic_node() instead of using > rtems_io_register_driver(). Another option is to use the new I2C framework. > > If you really need this new application configuration option, then > please document it: > > https://docs.rtems.org/branches/master/eng/req/howto.html#application-configuration-options > Thanks for the review and suggestions. I am unsure how much work it would be to refactor the BSP to use the new I2C framework, but that is likely the neatest approach. For now, I will send a v2 of this patchset with documentation. It would be good to have libi2c working on mvme3100 in RTEMS 6. Best regards, Vijay > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 2/3] confdefs: Add configure macro for libi2c
Hi Sebastian, On Mon, Jul 24, 2023 at 10:09 AM Sebastian Huber wrote: > > On 20.07.23 03:10, Vijay Kumar Banerjee wrote: > > Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define > > Do we really need this? What happens if an I2C device needs interrupts > during initialization? > the libi2c initialize calls rtems_io_register_driver, which requires `CONFIGURE_MAXIMUM_DRIVERS` defined from the application. In some BSPs, like mvme3100, libi2c is initialized at sysinit, causing the application to crash without the define. Adding this confdefs macro allows the user to add the libi2c if it is needed by the app, or omit it without crashing the system. In its current state, libi2c requires the BSP to handle registering the buses and drivers after initialization, the interrupt can be handled by the BSP I2C handler. > -- > embedded brains GmbH > Herr Sebastian HUBER > Dornierstr. 4 > 82178 Puchheim > Germany > email: sebastian.hu...@embedded-brains.de > phone: +49-89-18 94 741 - 16 > fax: +49-89-18 94 741 - 08 > > Registergericht: Amtsgericht München > Registernummer: HRB 157899 > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > Unsere Datenschutzerklärung finden Sie hier: > https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH RSB] rtems-net-legacy: Update net and waf versions
Thanks. Pushed.
On Wed, Jul 19, 2023 at 8:44 PM Chris Johns wrote:
>
> Looks good.
>
> Thanks
> Chris
>
> On 20/7/2023 11:17 am, Vijay Kumar Banerjee wrote:
> > ---
> > rtems/config/tools/rtems-net-legacy-6.cfg | 8
> > 1 file changed, 4 insertions(+), 4 deletions(-)
> >
> > diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
> > b/rtems/config/tools/rtems-net-legacy-6.cfg
> > index 9193a58..559ec01 100644
> > --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> > +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> > @@ -3,10 +3,10 @@
> > #
> >
> > # branch: main
> > -%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
> > +%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
> > %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> > -
> > EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
> > -%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> > +
> > ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
> > +%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
> > %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> > -
> > gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> > +
> > NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
> > %include tools/rtems-net-legacy-common.cfg
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
On Wed, Jul 19, 2023 at 7:56 PM Vijay Kumar Banerjee wrote: > > On Wed, Jul 19, 2023 at 7:50 PM Chris Johns wrote: > > > > On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote: > > > On Wed, Jul 19, 2023 at 6:39 PM Chris Johns wrote: > > >> > > >> Excellent. > > >> > > >> Could you please update the hash in the RSB for the net legacy package? > > >> Updating net legacy version and waf version: https://lists.rtems.org/pipermail/devel/2023-July/075839.html > > > Thanks for mentioning it! While trying to build from RSB, I realized > > > two important changes I need from rtems build: > > > 1. Removing networking check, put a patch for it just now: > > > https://lists.rtems.org/pipermail/devel/2023-July/075830.html > > > > I saw that. > > > > > 2. Building the ping and telnetd02 requires posix. For this, should be > > > conditionally build these two tests only when RTEMS_POSIX_API is true? > > > > Which part of POSIX is needed? I ask because I think the POSIX option is > > only > > controlling signals and maybe something else, > Signals only, yes. > > > I cannot remember what the list > > is. What happens if you remove the check? > > ``` > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > ./libnetworking.a(main_ping.c.3.o): in function `main_ping': > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:684: > undefined reference to `alarm' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:987: > undefined reference to `sigaction' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1000: > undefined reference to `sigaction' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > ./libnetworking.a(main_ping.c.3.o): in function `g_finish': > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1620: > undefined reference to `signal' > /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: > /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1621: > undefined reference to `signal' > collect2: error: ld returned 1 exit status > > ``` > > > > > > > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH RSB] rtems-net-legacy: Update net and waf versions
---
rtems/config/tools/rtems-net-legacy-6.cfg | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
b/rtems/config/tools/rtems-net-legacy-6.cfg
index 9193a58..559ec01 100644
--- a/rtems/config/tools/rtems-net-legacy-6.cfg
+++ b/rtems/config/tools/rtems-net-legacy-6.cfg
@@ -3,10 +3,10 @@
#
# branch: main
-%define rtems_net_version ba35f73d2ddc82d2b9a7b728dc63552be2274968
+%define rtems_net_version 3a83bcef4bd62fda5c0f9c94dd649fc32d962ab2
%hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
-
EljXAoCCIpFgncarsSR9V/WczB3VO9+VqTsJfrkvOCpwCuO8SWY6GTM46DnvyKBUrmkv0Rk+0TBdOifuYaMMug==
-%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
+
ANUrgSU3YRAnbEM/9wL5R4LrRCcyDYZz9KbRhTxnNYvUPjrfNgO+bM1qEYtJI6qUxvlKZYkVIkeOKxsAtjj1/A==
+%define rtems_waf_version 68654b4f995382765605dc16917baad4bdbf7f7c
%hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
-
gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
+
NAuyFxjfSiQd6VfYZl4fJClywPrLF2fN+GjXHjq3ddceqaBrSeHZ+XpYpU3XTnk2qKICsUSTLV+CskDuWdwqvQ==
%include tools/rtems-net-legacy-common.cfg
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h
Pushed. Thanks! On Wed, Jul 19, 2023 at 7:51 PM Chris Johns wrote: > > Looks good. > > Thanks > Chris > > On 20/7/2023 10:15 am, Vijay Kumar Banerjee wrote: > > --- > > bsps/powerpc/beatnik/include/bsp.h | 2 -- > > 1 file changed, 2 deletions(-) > > > > diff --git a/bsps/powerpc/beatnik/include/bsp.h > > b/bsps/powerpc/beatnik/include/bsp.h > > index 477f03345d..a70bb3997f 100644 > > --- a/bsps/powerpc/beatnik/include/bsp.h > > +++ b/bsps/powerpc/beatnik/include/bsp.h > > @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void); > > int BSP_i2c_initialize(void); > > > > /* Networking; */ > > -#if defined(RTEMS_NETWORKING) > > #include > > int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int); > > int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int); > > int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int); > > -#endif > > > > /* NOT FOR PUBLIC USE BELOW HERE */ > > #define BSP_PCI_HOSE0_MEM_BASE0x8000 /* must be aligned to size */ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 3/3] mvme3100: Initialize libi2c at device driver order
To use the libi2c, application needs to be configured with
#define CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
---
bsps/powerpc/mvme3100/i2c/i2c_init.c | 11 ++-
bsps/powerpc/mvme3100/start/bspstart.c | 2 +-
2 files changed, 7 insertions(+), 6 deletions(-)
diff --git a/bsps/powerpc/mvme3100/i2c/i2c_init.c
b/bsps/powerpc/mvme3100/i2c/i2c_init.c
index 9e242baf20..7e6fb50020 100644
--- a/bsps/powerpc/mvme3100/i2c/i2c_init.c
+++ b/bsps/powerpc/mvme3100/i2c/i2c_init.c
@@ -86,13 +86,14 @@ BSP_i2c_initialize(void)
{
int busno, succ = 0;
- /* Initialize the library */
- if ( rtems_libi2c_initialize() ) {
- safe_printf("Initializing I2C library failed\n");
- return -1;
- }
+ /* Library initialize by io module */
/* Register our bus driver */
+if (!rtems_libi2c_is_initialized){
+safe_printf("LIBI2C NOT INITIALIZED\n");
+return -1;
+}
+
if ( (busno=rtems_libi2c_register_bus(
BSP_I2C_BUS0_NAME,
BSP_I2C_BUS_DESCRIPTOR) ) < 0 ) {
diff --git a/bsps/powerpc/mvme3100/start/bspstart.c
b/bsps/powerpc/mvme3100/start/bspstart.c
index f27304c144..97faefed35 100644
--- a/bsps/powerpc/mvme3100/start/bspstart.c
+++ b/bsps/powerpc/mvme3100/start/bspstart.c
@@ -436,7 +436,7 @@ static void mvme3100_i2c_initialize(void)
RTEMS_SYSINIT_ITEM(
mvme3100_i2c_initialize,
- RTEMS_SYSINIT_BSP_PRE_DRIVERS,
+ RTEMS_SYSINIT_DEVICE_DRIVERS,
RTEMS_SYSINIT_ORDER_MIDDLE
);
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] confdefs: Add configure macro for libi2c
Add CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER define
---
cpukit/include/rtems/confdefs/iodrivers.h | 8
1 file changed, 8 insertions(+)
diff --git a/cpukit/include/rtems/confdefs/iodrivers.h
b/cpukit/include/rtems/confdefs/iodrivers.h
index 16d64fbb98..cf5530fe2b 100644
--- a/cpukit/include/rtems/confdefs/iodrivers.h
+++ b/cpukit/include/rtems/confdefs/iodrivers.h
@@ -60,6 +60,7 @@
defined(CONFIGURE_APPLICATION_NEEDS_IDE_DRIVER) || \
defined(CONFIGURE_APPLICATION_NEEDS_ATA_DRIVER) || \
defined(CONFIGURE_APPLICATION_NEEDS_FRAME_BUFFER_DRIVER) || \
+ defined(CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER) || \
defined(CONFIGURE_APPLICATION_EXTRA_DRIVERS)
#define _CONFIGURE_HAS_IO_DRIVERS
#endif
@@ -112,6 +113,10 @@
#include
#endif
+#ifdef CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
+ #include
+#endif
+
#ifndef CONFIGURE_MAXIMUM_DRIVERS
#define CONFIGURE_MAXIMUM_DRIVERS
#endif
@@ -157,6 +162,9 @@ _IO_Driver_address_table[ CONFIGURE_MAXIMUM_DRIVERS ] = {
#ifdef CONFIGURE_APPLICATION_EXTRA_DRIVERS
CONFIGURE_APPLICATION_EXTRA_DRIVERS,
#endif
+ #ifdef CONFIGURE_APPLICATION_NEEDS_LIBI2C_DRIVER
+RTEMS_LIBI2C_DRIVER_TABLE_ENTRY,
+ #endif
#if defined(CONFIGURE_APPLICATION_NEEDS_NULL_DRIVER) || \
!defined(_CONFIGURE_HAS_IO_DRIVERS)
NULL_DRIVER_TABLE_ENTRY
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 1/3] libi2c: Use rtems thread api
Replace custom mutex handling with rtems thread api
---
cpukit/include/rtems/libi2c.h | 2 +
cpukit/libi2c/libi2c.c| 114 +++---
2 files changed, 37 insertions(+), 79 deletions(-)
diff --git a/cpukit/include/rtems/libi2c.h b/cpukit/include/rtems/libi2c.h
index 7b86ab5f99..b8a4a5e5d9 100644
--- a/cpukit/include/rtems/libi2c.h
+++ b/cpukit/include/rtems/libi2c.h
@@ -119,6 +119,8 @@ rtems_i2c_ioctl (
extern const rtems_driver_address_table rtems_libi2c_io_ops;
+extern bool rtems_libi2c_is_initialized;
+
/* Unfortunately, if you want to add this driver to
* a RTEMS configuration table then you need all the
* members explicitly :-( (Device_driver_table should
diff --git a/cpukit/libi2c/libi2c.c b/cpukit/libi2c/libi2c.c
index 027c4859c1..53f17d878e 100644
--- a/cpukit/libi2c/libi2c.c
+++ b/cpukit/libi2c/libi2c.c
@@ -64,6 +64,7 @@
#include
#include
#include
+#include
#include
@@ -103,35 +104,22 @@
rtems_device_major_number rtems_libi2c_major;
-static bool is_initialized = false;
+bool rtems_libi2c_is_initialized = false;
static struct i2cbus
{
rtems_libi2c_bus_t *bush;
- volatile rtems_id mutex; /* lock this across start -> stop */
+ rtems_mutex mutex; /* lock this across start -> stop */
volatile bool started;
char *name;
-} busses[MAX_NO_BUSSES] = { { NULL, RTEMS_ID_NONE, false, NULL } };
+} busses[MAX_NO_BUSSES] = { { NULL, {}, false, NULL } };
static struct
{
rtems_libi2c_drv_t *drv;
} drvs[MAX_NO_DRIVERS] = { { NULL } };
-static rtems_id libmutex = RTEMS_ID_NONE;
-
-#define LOCK(m)assert(!rtems_semaphore_obtain((m), RTEMS_WAIT,
RTEMS_NO_TIMEOUT))
-#define UNLOCK(m) rtems_semaphore_release((m))
-
-#define LIBLOCK() LOCK(libmutex)
-#define LIBUNLOCK()UNLOCK(libmutex)
-
-#define MUTEX_ATTS \
- ( RTEMS_PRIORITY \
-| RTEMS_BINARY_SEMAPHORE \
-|RTEMS_INHERIT_PRIORITY\
-|RTEMS_NO_PRIORITY_CEILING \
-|RTEMS_LOCAL )
+static rtems_mutex libmutex;
/* During early stages of life, stdio is not available */
@@ -148,21 +136,6 @@ va_list ap;
va_end(ap);
}
-static rtems_status_code
-mutexCreate (rtems_name nm, rtems_id *pm)
-{
- rtems_status_code sc;
-
- if (RTEMS_SUCCESSFUL !=
- (sc = rtems_semaphore_create (nm, 1, MUTEX_ATTS, 0, pm))) {
- if ( _System_state_Is_up( _System_state_Get() ) )
- rtems_error (sc, DRVNM "Unable to create mutex\n");
- else
- printk (DRVNM "Unable to create mutex (status code %i)\n", sc);
- }
- return sc;
-}
-
/* Lock a bus avoiding to have a mutex, which is mostly
* unused, hanging around all the time. We just create
* and delete it on the fly...
@@ -174,37 +147,27 @@ static void
lock_bus (int busno)
{
struct i2cbus *bus = [busno];
+ char name[5];
- if (bus->mutex == RTEMS_ID_NONE) {
-/*
- * Nobody is holding the bus mutex - it's not there. Create it on the fly.
- */
-LIBLOCK ();
-if (bus->mutex == RTEMS_ID_NONE) {
- rtems_id m = RTEMS_ID_NONE;
- rtems_status_code sc = mutexCreate (
-rtems_build_name ('i', '2', 'c', '0' + busno),
-
- );
- if (sc != RTEMS_SUCCESSFUL) {
-LIBUNLOCK ();
-rtems_panic (DRVNM "Unable to create bus lock");
-return;
- }
- bus->mutex = m;
-}
-LIBUNLOCK ();
- }
+ rtems_mutex_lock();
+
+ snprintf(name, 5, "I2C%d", busno);
+
+ rtems_mutex_init(>mutex, name);
+
+ rtems_mutex_unlock();
/* Now lock this bus */
- LOCK (bus->mutex);
+
+ rtems_mutex_lock(>mutex);
}
static void
unlock_bus (int busno)
{
struct i2cbus *bus = [busno];
- UNLOCK (bus->mutex);
+
+ rtems_mutex_unlock(>mutex);
}
/* Note that 'arg' is always passed in as NULL */
@@ -212,21 +175,16 @@ rtems_status_code
rtems_i2c_init (rtems_device_major_number major, rtems_device_minor_number
minor,
void *arg)
{
- rtems_status_code rval;
/* No busses or drivers can be registered at this point;
* avoid the macro aborting with an error
DECL_CHECKED_DRV (drv, busno, minor)
*/
- rval = mutexCreate (rtems_build_name ('l', 'I', '2', 'C'), );
+ rtems_mutex_init(, "LIBI2C");
+ rtems_libi2c_is_initialized = true;
+ rtems_libi2c_major = major;
+ return 0;
- if ( RTEMS_SUCCESSFUL == rval ) {
- is_initialized = true;
- rtems_libi2c_major = major;
- } else {
- libmutex = RTEMS_ID_NONE;
- }
- return rval;
}
rtems_status_code
@@ -350,7 +308,7 @@ rtems_libi2c_initialize (void)
{
rtems_status_code sc;
- if (is_initialized) {
+ if (rtems_libi2c_is_initialized) {
/*
* already called before? then skip this step
*/
@@ -361,18 +319,15 @@ rtems_libi2c_initialize (void)
* the return code of the 'init' operation, so we cannot
* rely on return code since it may seem OK even if the driver 'init;
* op failed.
- * Let 'init' handle
Re: [PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
On Wed, Jul 19, 2023 at 7:50 PM Chris Johns wrote: > > On 20/7/2023 10:18 am, Vijay Kumar Banerjee wrote: > > On Wed, Jul 19, 2023 at 6:39 PM Chris Johns wrote: > >> > >> Excellent. > >> > >> Could you please update the hash in the RSB for the net legacy package? > >> > > Thanks for mentioning it! While trying to build from RSB, I realized > > two important changes I need from rtems build: > > 1. Removing networking check, put a patch for it just now: > > https://lists.rtems.org/pipermail/devel/2023-July/075830.html > > I saw that. > > > 2. Building the ping and telnetd02 requires posix. For this, should be > > conditionally build these two tests only when RTEMS_POSIX_API is true? > > Which part of POSIX is needed? I ask because I think the POSIX option is only > controlling signals and maybe something else, Signals only, yes. > I cannot remember what the list > is. What happens if you remove the check? ``` /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: ./libnetworking.a(main_ping.c.3.o): in function `main_ping': /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:684: undefined reference to `alarm' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:987: undefined reference to `sigaction' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1000: undefined reference to `sigaction' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: ./libnetworking.a(main_ping.c.3.o): in function `g_finish': /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1620: undefined reference to `signal' /home/vijay/development/rtems/6/lib/gcc/powerpc-rtems6/10.3.1/../../../../powerpc-rtems6/bin/ld: /home/vijay/development/rtems-net-legacy/build/powerpc-rtems6-beatnik/../../libmisc/main_ping.c:1621: undefined reference to `signal' collect2: error: ld returned 1 exit status ``` > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] powerpc/beatnik: Remove RTEMS_NETWORKING check from bsp.h
--- bsps/powerpc/beatnik/include/bsp.h | 2 -- 1 file changed, 2 deletions(-) diff --git a/bsps/powerpc/beatnik/include/bsp.h b/bsps/powerpc/beatnik/include/bsp.h index 477f03345d..a70bb3997f 100644 --- a/bsps/powerpc/beatnik/include/bsp.h +++ b/bsps/powerpc/beatnik/include/bsp.h @@ -173,12 +173,10 @@ extern void BSP_motload_pci_fixup(void); int BSP_i2c_initialize(void); /* Networking; */ -#if defined(RTEMS_NETWORKING) #include int rtems_em_attach(struct rtems_bsdnet_ifconfig *, int); int rtems_dec21140_driver_attach(struct rtems_bsdnet_ifconfig *, int); int rtems_dc_driver_attach(struct rtems_bsdnet_ifconfig *, int); -#endif /* NOT FOR PUBLIC USE BELOW HERE */ #define BSP_PCI_HOSE0_MEM_BASE0x8000 /* must be aligned to size */ -- 2.34.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-net-legacy] powerpc/beatnik: Add mv643xx_eth.c driver from RTEMS 5
---
bsp_drivers.py|2 +
bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c | 3318 +
2 files changed, 3320 insertions(+)
create mode 100644 bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
diff --git a/bsp_drivers.py b/bsp_drivers.py
index e2250aa..5628ff3 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -79,6 +79,7 @@ include = {
'bsps/powerpc/beatnik/net',
'bsps/powerpc/beatnik/net/if_em',
'bsps/powerpc/beatnik/net/if_gfe',
+'bsps/powerpc/beatnik/net/if_mve',
'bsps/powerpc/beatnik/net/porting',
],
'powerpc/mpc8260ads': [
@@ -174,6 +175,7 @@ source = {
'bsps/powerpc/beatnik/net/if_em/if_em_rtems.c',
'bsps/powerpc/beatnik/net/if_gfe/if_gfe.c',
'bsps/powerpc/beatnik/net/if_gfe/if_gfe_rtems.c',
+'bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c',
'bsps/powerpc/beatnik/net/porting/if_xxx_rtems.c',
'bsps/powerpc/beatnik/net/support/bsp_attach.c',
'bsps/powerpc/beatnik/net/support/early_link_status.c',
diff --git a/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
new file mode 100644
index 000..85ab038
--- /dev/null
+++ b/bsps/powerpc/beatnik/net/if_mve/mv643xx_eth.c
@@ -0,0 +1,3318 @@
+/* RTEMS driver for the mv643xx gigabit ethernet chip */
+
+/* Acknowledgement:
+ *
+ * Valuable information for developing this driver was obtained
+ * from the linux open-source driver mv643xx_eth.c which was written
+ * by the following people and organizations:
+ *
+ * Matthew Dharm
+ * rab...@galileo.co.il
+ * PMC-Sierra, Inc., Manish Lachwani
+ * Ralf Baechle
+ * MontaVista Software, Inc., Dale Farnsworth
+ * Steven J. Hill /
+ *
+ * Note however, that in spite of the identical name of this file
+ * (and some of the symbols used herein) this file provides a
+ * new implementation and is the original work by the author.
+ */
+
+/*
+ * Authorship
+ * --
+ * This software (mv643xx ethernet driver for RTEMS) was
+ * created by Till Straumann , 2005-2007,
+ *Stanford Linear Accelerator Center, Stanford University.
+ *
+ * Acknowledgement of sponsorship
+ * --
+ * The 'mv643xx ethernet driver for RTEMS' was produced by
+ * the Stanford Linear Accelerator Center, Stanford University,
+ *under Contract DE-AC03-76SFO0515 with the Department of Energy.
+ *
+ * Government disclaimer of liability
+ * --
+ * Neither the United States nor the United States Department of Energy,
+ * nor any of their employees, makes any warranty, express or implied, or
+ * assumes any legal liability or responsibility for the accuracy,
+ * completeness, or usefulness of any data, apparatus, product, or process
+ * disclosed, or represents that its use would not infringe privately owned
+ * rights.
+ *
+ * Stanford disclaimer of liability
+ *
+ * Stanford University makes no representations or warranties, express or
+ * implied, nor assumes any liability for the use of this software.
+ *
+ * Stanford disclaimer of copyright
+ *
+ * Stanford University, owner of the copyright, hereby disclaims its
+ * copyright and all other rights in this software. Hence, anyone may
+ * freely use it for any purpose without restriction.
+ *
+ * Maintenance of notices
+ * --
+ * In the interest of clarity regarding the origin and status of this
+ * SLAC software, this and all the preceding Stanford University notices
+ * are to remain affixed to any copy or derivative of this software made
+ * or distributed by the recipient and are to be affixed to any copy of
+ * software made or distributed by the recipient that contains a copy or
+ * derivative of this software.
+ *
+ * -- SLAC Software Notices, Set 4 OTT.002a, 2004 FEB 03
+ */
+
+/*
+ * NOTE: Some register (e.g., the SMI register) are SHARED among the
+ * three devices. Concurrent access protection is provided by
+ * the global networking semaphore.
+ * If other drivers are running on a subset of IFs then proper
+ * locking of all shared registers must be implemented!
+ *
+ * Some things I learned about this hardware can be found
+ * further down...
+ */
+
+#ifndef KERNEL
+#define KERNEL
+#endif
+#ifndef _KERNEL
+#define _KERNEL
+#endif
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+/* Not so nice; would be more elegant not to depend on C library but the
+ * RTEMS-specific ioctl for dumping statistics needs stdio anyways.
+ */
+
+/*#define NDEBUG effectively removes all assertions
+ * If defining NDEBUG, MAKE SURE assert() EXPRESSION HAVE NO SIDE_EFFECTS!!
+ * This driver DOES have side-effects, so DONT DEFINE NDEBUG
+ * Performance-critical assertions are
Re: [rtems-source-builder PATCH] rtems: Update tools, kernel and legacy network packages
Hi Chris,
The updates look good to me. Thanks.
On Fri, Apr 14, 2023 at 7:10 PM wrote:
>
> From: Chris Johns
>
> - Tools picks up the stm32h7-stlink to handle SIGTRAP fix.
>
> - RTEMS picks up the motorola_powerpc updates including the mvme2700
> BSP and Makefile.inc fixes for building EPICS.
>
> - Legacy networking picks up a number of build system fixes,
> network configuration changes and more tests.
> ---
> rtems/config/tools/rtems-kernel-6.cfg | 6 +++---
> rtems/config/tools/rtems-net-legacy-6.cfg | 8
> rtems/config/tools/rtems-tools-6.cfg | 4 ++--
> 3 files changed, 9 insertions(+), 9 deletions(-)
>
> diff --git a/rtems/config/tools/rtems-kernel-6.cfg
> b/rtems/config/tools/rtems-kernel-6.cfg
> index 0ee1d04..e2f1d68 100644
> --- a/rtems/config/tools/rtems-kernel-6.cfg
> +++ b/rtems/config/tools/rtems-kernel-6.cfg
> @@ -1,11 +1,11 @@
> #
> -# RTEMS 5
> +# RTEMS 6
> #
>
> -%define rtems_kernel_version d0b92735b0dfd509e1edb82c7145042b67714f43
> +%define rtems_kernel_version 5a37722b066f5792aad80fb5b32fb3c056cf1607
>
> %hash sha512 rtems-kernel-%{rtems_kernel_version}.tar.bz2 \
> -
> XyW9t5NSWAU8eAz1HdbFwOWmLMkAHeheeATznvag57QjP4rZYFeHfIws4ttzmSvODHDI16OJw/CLWQQ9l58SIg==
> +
> UcZlhl2FZhvDKXZnPLnJSYnMQwSgWluTBGfoLII9vNbx4ypxQPE+egN4dZ06H3l5MprrJY96mgNZTfLjI2itcQ==
> #
> # The RTEMS build instructions.
> #
> diff --git a/rtems/config/tools/rtems-net-legacy-6.cfg
> b/rtems/config/tools/rtems-net-legacy-6.cfg
> index fbc7ab8..984ba09 100644
> --- a/rtems/config/tools/rtems-net-legacy-6.cfg
> +++ b/rtems/config/tools/rtems-net-legacy-6.cfg
> @@ -3,10 +3,10 @@
> #
>
> # branch: main
> -%define rtems_net_version 5713f7027984012ea17cdd582e6d0258ee7aa58a
> +%define rtems_net_version d22fbcb0412e309850c0f49ab61bc410184b9b5c
> %hash sha512 rtems-net-legacy-%{rtems_net_version}.tar.bz2 \
> -
> 0dwnqZP+j9b2IZ7rqiEBndVkqIsURal4L/47pSI4pe0rz48hmWa78DE0915Gf+/+nvsCMB2I/sFAMj+P6AjeeA==
> -%define rtems_waf_version 1a118bbcd52138dbdc3236e64bc23fd430a064b1
> +
> eKESsJ4ra5kbF+IjMvhlLriGUxC2vCfKy/7bnkZyrhcBnfkpIWWqzEj1eB2iqfpy/1p+hcnxIh00ysJF66ptkw==
> +%define rtems_waf_version 2c15b90de5c369aa78cd2252a50bba677e9b13f3
> %hash sha512 rtems-waf-%{rtems_waf_version}.tar.bz2 \
> -
> wHiMBCaJjnNd8EEnbl5A9qyGwcQ5E+BcG9Q5SwJmlbarcrQ4U6//Q2ni2XNyXtWQzzy959o6YSg8PvVjgEi0vg==
> +
> gSpj/vTcB9T985HC9xi//gMcYj9rl6AedULvPdFppJ7D1CFIueE+MyfGn+okVtZvnG+tZk1JkR2gvIQNV3mXbQ==
> %include tools/rtems-net-legacy-common.cfg
> diff --git a/rtems/config/tools/rtems-tools-6.cfg
> b/rtems/config/tools/rtems-tools-6.cfg
> index 042e0fa..b786a47 100644
> --- a/rtems/config/tools/rtems-tools-6.cfg
> +++ b/rtems/config/tools/rtems-tools-6.cfg
> @@ -10,14 +10,14 @@
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %define rtems_tools_ext xz
> %else
> - %define rtems_tools_version c8bf7309332990a52ae98ed3926c0f62984e8193
> + %define rtems_tools_version eaf14a654b528b44de14f9da9919555e54324e0d
> %define rtems_tools_ext bz2
> %endif
>
> %define rtems_tools_source rtems-tools-%{rtems_tools_version}
> %source set rtems-tools
> https://git.rtems.org/rtems-tools/snapshot/%{rtems_tools_source}.tar.%{rtems_tools_ext}
> %hash sha512 rtems-tools-%{rtems_tools_version}.tar.bz2 \
> -
> XOCIuPQ65yZOvPkiTZb3r2T9YAPBg6az3xz5Z2ivkfygSYZgaymSkmpv5yF3QbCXK1Y+2LRUuEp73oymj7vnbA==
> +
> bcjVLITKdjQLKlalfUptMKLAmvDT0FidARukQHP4rK/8SWpYckPAc8BMMRhS3RX+Ga6NDuxD1Ss/bRlxG6qsdg==
>
> #
> # Optionally enable/disable building the RTEMS Tools via the command line.
> --
> 2.31.1
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [rtems-net-legacy PATCH] waf: Generate a version header called rtems-net-legacy.h
Hi Chris,
The patch looks great. Thanks.
On Thu, Apr 13, 2023 at 11:21 PM wrote:
>
> From: Chris Johns
>
> ---
> include/rtems/rtems-net-legacy.h.in | 42 +
> netlegacy.py| 35 +---
> rtems_waf | 2 +-
> 3 files changed, 75 insertions(+), 4 deletions(-)
> create mode 100755 include/rtems/rtems-net-legacy.h.in
>
> diff --git a/include/rtems/rtems-net-legacy.h.in
> b/include/rtems/rtems-net-legacy.h.in
> new file mode 100755
> index 000..a17ec21
> --- /dev/null
> +++ b/include/rtems/rtems-net-legacy.h.in
> @@ -0,0 +1,42 @@
> +/**
> + * @file
> + *
> + * @ingroup rtems_net_legacy
> + *
> + * @brief This file is generated
> + */
> +
> +/*
> + * Copyright (c) 2023. Chris Johns . All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR AND CONTRIBUTORS ``AS IS'' AND
> + * ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR CONTRIBUTORS BE LIABLE
> + * FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
> + * DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS
> + * OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
> + * HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT
> + * LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY
> + * OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF
> + * SUCH DAMAGE.
> + */
> +
> +#ifndef _RTEMS_NET_LGEACY_H_
> +#define _RTEMS_NET_LEGACY_H_
> +
> +#define RTEMS_NET_LEGACY_VERSION @RTEMS_NET_LEGACY_VERSION@
> +
> +#define RTEMS_NET_LEGACY_MAJOR@RTEMS_NET_LEGACY_MAJOR@
> +#define RTEMS_NET_LEGACY_REVISION @RTEMS_NET_LEGACY_REVISION@
> +
> +#endif /* _RTEMS_NET_LGEACY_H_ */
> diff --git a/netlegacy.py b/netlegacy.py
> index 60775dc..9f27ffc 100644
> --- a/netlegacy.py
> +++ b/netlegacy.py
> @@ -29,12 +29,31 @@
> import os
> import os.path
>
> +from rtems_waf import git
> from rtems_waf import rtems
> +from rtems_waf import version
>
> import bsp_drivers
> import netsources
>
>
> +def version_header(bld):
> +versions = {
> +'RTEMS_NET_LEGACY_VERSION':
> +'"' + bld.env.RTEMS_NET_LEGACY_VERSION + '"',
> +'RTEMS_NET_LEGACY_MAJOR': bld.env.RTEMS_NET_LEGACY_MAJOR,
> +'RTEMS_NET_LEGACY_REVISION':
> +'"' + bld.env.RTEMS_NET_LEGACY_REVISION + '"',
> +}
> +sed = 'sed '
> +for cfg in versions:
> +sed += "-e 's/@%s@/%s/' " % (cfg, versions[cfg])
> +bld(target='include/rtems/rtems-net-legacy.h',
> +source='include/rtems/rtems-net-legacy.h.in',
> +rule=sed + ' < ${SRC} > ${TGT}',
> +update_outputs=True)
> +
> +
> def net_config_header(bld):
> if not os.path.exists(bld.env.NET_CONFIG):
> bld.fatal('network configuraiton \'%s\' not found' %
> @@ -88,7 +107,14 @@ def options(opt):
>
>
> def bsp_configure(conf, arch_bsp, mandatory=True):
> -ab = rtems.arch(arch_bsp) + '/' + rtems.bsp(arch_bsp)
> +conf.start_msg('Checking version')
> +version.load_rtems_version_header(conf, conf.env.RTEMS_VERSION, arch_bsp,
> + conf.env.IFLAGS)
> +conf.env.RTEMS_NET_LEGACY_VERSION = version.string(conf)
> +conf.env.RTEMS_NET_LEGACY_MAJOR = version.version(conf)
> +conf.env.RTEMS_NET_LEGACY_REVISION = version.revision(conf)
> +conf.end_msg(conf.env.RTEMS_NET_LEGACY_VERSION)
> +ab = rtems.arch_bsp_name(arch_bsp)
> includes = [
> '.',
> 'include',
> @@ -125,9 +151,9 @@ def bsp_configure(conf, arch_bsp, mandatory=True):
>
>
> def build(bld):
> -arch_bsp = bld.env.RTEMS_ARCH_BSP
> -ab = rtems.arch(arch_bsp) + '/' + rtems.bsp(arch_bsp)
> +ab = rtems.arch_bsp_name(bld.env.RTEMS_ARCH_BSP)
>
> +version_header(bld)
> net_config_header(bld)
>
> if ab in bsp_drivers.source:
> @@ -173,3 +199,6 @@ def build(bld):
> bld.install_as(
> os.path.join(bld.env.PREFIX, arch_inc_path, inc_dir, hname),
> header)
> +bld.install_as(
> +os.path.join(bld.env.PREFIX, arch_inc_path, 'rtems',
> + 'rtems-net-legacy.h'),
> 'include/rtems/rtems-net-legacy.h')
> diff --git a/rtems_waf b/rtems_waf
> index
[PATCH rtems-net-legacy] leon3: Replace ambapp_plb with ambapp_plb()
RTEMS commit 2c07f24af210c4738fbe6f75a53c58fbd80fb658 removed the ambapp_plb
global variable
---
bsps/sparc/leon3/net/leon_greth.c| 3 ++-
bsps/sparc/leon3/net/leon_open_eth.c | 5 +++--
bsps/sparc/leon3/net/leon_smc9.c | 11 ++-
3 files changed, 11 insertions(+), 8 deletions(-)
diff --git a/bsps/sparc/leon3/net/leon_greth.c
b/bsps/sparc/leon3/net/leon_greth.c
index 5b0c99d..934728f 100644
--- a/bsps/sparc/leon3/net/leon_greth.c
+++ b/bsps/sparc/leon3/net/leon_greth.c
@@ -13,6 +13,7 @@
#include
#include
+#include
/*#if (GRETH_DEBUG & GRETH_DEBUG_PRINT_REGISTERS)*/
#include
/*#endif*/
@@ -36,7 +37,7 @@ int rtems_leon_greth_driver_attach(
struct ambapp_apb_info *apb;
/* Scan for MAC AHB slave interface */
- adev = (void *)ambapp_for_each(_plb, (OPTIONS_ALL|OPTIONS_APB_SLVS),
+ adev = (void *)ambapp_for_each(ambapp_plb(), (OPTIONS_ALL|OPTIONS_APB_SLVS),
VENDOR_GAISLER, GAISLER_ETHMAC,
ambapp_find_by_idx, NULL);
if (adev) {
diff --git a/bsps/sparc/leon3/net/leon_open_eth.c
b/bsps/sparc/leon3/net/leon_open_eth.c
index 2b386f8..315f6b7 100644
--- a/bsps/sparc/leon3/net/leon_open_eth.c
+++ b/bsps/sparc/leon3/net/leon_open_eth.c
@@ -17,6 +17,7 @@
#include
#include
+#include
#if (OPEN_ETH_DEBUG & OPEN_ETH_DEBUG_PRINT_REGISTERS)
#include
#endif
@@ -40,11 +41,11 @@ int rtems_leon_open_eth_driver_attach(
struct ambapp_ahb_info *ahb;
/* Scan for MAC AHB slave interface */
- adev = (void *)ambapp_for_each(_plb, (OPTIONS_ALL|OPTIONS_AHB_SLVS),
+ adev = (void *)ambapp_for_each(ambapp_plb(), (OPTIONS_ALL|OPTIONS_AHB_SLVS),
VENDOR_OPENCORES, OPENCORES_ETHMAC,
ambapp_find_by_idx, NULL);
if (!adev) {
-adev = (void *)ambapp_for_each(_plb, (OPTIONS_ALL|OPTIONS_AHB_SLVS),
+adev = (void *)ambapp_for_each(ambapp_plb(),
(OPTIONS_ALL|OPTIONS_AHB_SLVS),
VENDOR_GAISLER, GAISLER_ETHAHB,
ambapp_find_by_idx, NULL);
}
diff --git a/bsps/sparc/leon3/net/leon_smc9.c
b/bsps/sparc/leon3/net/leon_smc9.c
index 70b2dcc..6577f28 100644
--- a/bsps/sparc/leon3/net/leon_smc9.c
+++ b/bsps/sparc/leon3/net/leon_smc9.c
@@ -19,6 +19,7 @@
#include
#include
#include
+#include
#define SMC9_BASE_ADDR (void*)0x2300
#define SMC9_BASE_IRQ 4
@@ -45,7 +46,7 @@ rtems_smc9_driver_attach_leon3 (struct
rtems_bsdnet_ifconfig *config,
struct ambapp_apb_info apbpio;
struct ambapp_apb_info apbmctrl;
- if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_GPIO, )
+ if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_GPIO, )
!= 1) {
printk("SMC9111_leon3: didn't find PIO\n");
return 0;
@@ -54,12 +55,12 @@ rtems_smc9_driver_attach_leon3 (struct
rtems_bsdnet_ifconfig *config,
/* In order to access the SMC controller the memory controller must have
* I/O bus enabled. Find first memory controller.
*/
- if (ambapp_find_apbslv(_plb, VENDOR_ESA, ESA_MCTRL, ) != 1) {
-if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_FTMCTRL,
+ if (ambapp_find_apbslv(ambapp_plb(), VENDOR_ESA, ESA_MCTRL, ) != 1)
{
+if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_FTMCTRL,
) != 1) {
- if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_FTSRCTRL,
+ if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_FTSRCTRL,
) != 1) {
-if (ambapp_find_apbslv(_plb, VENDOR_GAISLER, GAISLER_FTSRCTRL8,
+if (ambapp_find_apbslv(ambapp_plb(), VENDOR_GAISLER, GAISLER_FTSRCTRL8,
) != 1) {
printk("SMC9111_leon3: didn't find any memory controller\n");
return 0;
--
2.34.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] wscript: Allow deeper lwIP configuration
This is great! This makes it more adaptable with different BSPS. Also,
thanks for the documentation. :)
On Fri, Nov 11, 2022 at 3:03 PM Kinsey Moore wrote:
>
> This adds a basic configuration mechanism in config.ini to control which
> BSPs are enabled and to alter lwIP's define/macro-based configuration
> directives. Existing builds using --rtems-bsps are unaffected if
> config.ini is not used.
> ---
> README | 14 ++
> wscript | 60 -
> 2 files changed, 73 insertions(+), 1 deletion(-)
>
> diff --git a/README b/README
> index 99800bf..a8cbc21 100644
> --- a/README
> +++ b/README
> @@ -30,3 +30,17 @@ git submodule update
>
> More `waf` arguments can be found by using:
> `./waf --help`
> +
> +Further Build Information
> +-
> +
> +The BSPs configured to build may be specified on the waf configure command
> line
> +with --rtems-bsps or they may be configured in config.ini as in RTEMS. The
> +command line option will override the BSPs configured in config.ini, but
> options
> +in config.ini will still be applied for enabled BSPs. Any additional
> +configuration options desired in lwipopts.h may be specified in config.ini
> under
> +the appropriate section as key/value pairs like so:
> +
> +[aarch64/xilinx_zynqmp_lp64_zu3eg]
> +LWIP_IGMP=1
> +ZYNQMP_USE_SGMII=1
> diff --git a/wscript b/wscript
> index 1546a3d..f1b919e 100644
> --- a/wscript
> +++ b/wscript
> @@ -1,3 +1,5 @@
> +#!/usr/bin/env python
> +
> #
> # RTEMS Project (https://www.rtems.org/)
> #
> @@ -28,7 +30,13 @@
> from __future__ import print_function
> from rtems_waf import rtems
>
> +try:
> +import configparser
> +except:
> +import ConfigParser as configparser
> +
> import lwip
> +import os
> import sys
> top = '.'
>
> @@ -48,8 +56,58 @@ def options(opt):
> rtems.options(opt)
>
>
> +def no_unicode(value):
> +if sys.version_info[0] > 2:
> +return value
> +if isinstance(value, unicode):
> +return str(value)
> +return value
> +
> +
> +def get_config():
> +cp = configparser.ConfigParser()
> +filename = "config.ini"
> +if filename not in cp.read([filename]):
> +return None
> +return cp
> +
> +
> +def get_configured_bsps(cp):
> +if not cp:
> +return "all"
> +bsps = []
> +for raw_bsp in cp.sections():
> +bsps.append(no_unicode(raw_bsp))
> +return ",".join(bsps)
> +
> +
> +def get_configured_bsp_options(cp, arch, bsp):
> +if not cp:
> +return {}
> +options = {}
> +for config_option in cp.items(os.path.join(arch, bsp)):
> +opt_name = config_option[0].upper()
> +options[opt_name] = config_option[1]
> +return options
> +
> +
> +def bsp_configure(conf, arch_bsp):
> +cp = get_config()
> +arch = rtems.arch(arch_bsp)
> +bsp = rtems.bsp(arch_bsp)
> +config_options = get_configured_bsp_options(cp, arch, bsp)
> +for key, val in config_options.items():
> +flag = "-D"+key+"="+val
> +conf.env.CFLAGS.append(flag)
> +conf.env.CXXFLAGS.append(flag)
> +lwip.bsp_configure(conf, arch_bsp)
> +
> +
> def configure(conf):
> -rtems.configure(conf, lwip.bsp_configure)
> +cp = get_config()
> +if conf.options.rtems_bsps == "all":
> +conf.options.rtems_bsps = get_configured_bsps(cp)
> +rtems.configure(conf, bsp_configure)
>
>
> def build(bld):
> --
> 2.30.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] zynqmp: Add support for the CFC-400X BSP
Looks great. It only affects the Zynqmp.
Thanks.
On Thu, Nov 10, 2022 at 2:23 PM Kinsey Moore wrote:
>
> This adds support for the CFC-400X BSP including an option to select
> SGMII instead of the default RGMII PHY interface and adds a way for
> ZynqMP BSPs to provide additional configuration via lwipbspopts.h.
> ---
> .../aarch64/xilinx_zynqmp_lp64_cfc400x.json | 11
> .../contrib/ports/xilinx/netif/xemacpsif_hw.c | 6 ++
> rtemslwip/zynqmp/lwipopts.h | 2 +
> rtemslwip/zynqmp_cfc400x/lwipbspopts.h| 33 ++
> rtemslwip/zynqmp_cfc400x/netstart.c | 66 +++
> rtemslwip/zynqmp_hardware/lwipbspopts.h | 1 +
> rtemslwip/zynqmp_qemu/lwipbspopts.h | 1 +
> 7 files changed, 120 insertions(+)
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_lp64_cfc400x.json
> create mode 100644 rtemslwip/zynqmp_cfc400x/lwipbspopts.h
> create mode 100644 rtemslwip/zynqmp_cfc400x/netstart.c
> create mode 100644 rtemslwip/zynqmp_hardware/lwipbspopts.h
> create mode 100644 rtemslwip/zynqmp_qemu/lwipbspopts.h
>
> diff --git a/defs/bsps/aarch64/xilinx_zynqmp_lp64_cfc400x.json
> b/defs/bsps/aarch64/xilinx_zynqmp_lp64_cfc400x.json
> new file mode 100644
> index 000..5fe676c
> --- /dev/null
> +++ b/defs/bsps/aarch64/xilinx_zynqmp_lp64_cfc400x.json
> @@ -0,0 +1,11 @@
> +{
> + "includes": [
> + "xilinx_zynqmp_base"
> + ],
> + "header-paths-to-import": [
> + "rtemslwip/zynqmp_cfc400x"
> + ],
> + "source-paths-to-import": [
> + "rtemslwip/zynqmp_cfc400x"
> + ]
> +}
> diff --git
> a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c
>
> b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c
> index a1fdeda..f0ddf84 100644
> ---
> a/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c
> +++
> b/embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/netif/xemacpsif_hw.c
> @@ -74,6 +74,12 @@ void init_emacps(xemacpsif_s *xemacps, struct netif *netif)
>
> xemacpsp = >emacps;
>
> +#ifdef __rtems__
> +#ifdef ZYNQMP_USE_SGMII
> + XEmacPs_SetOptions(xemacpsp, XEMACPS_SGMII_ENABLE_OPTION);
> +#endif
> +#endif
> +
> #ifdef ZYNQMP_USE_JUMBO
> XEmacPs_SetOptions(xemacpsp, XEMACPS_JUMBO_ENABLE_OPTION);
> #endif
> diff --git a/rtemslwip/zynqmp/lwipopts.h b/rtemslwip/zynqmp/lwipopts.h
> index b9fe277..feabe73 100644
> --- a/rtemslwip/zynqmp/lwipopts.h
> +++ b/rtemslwip/zynqmp/lwipopts.h
> @@ -123,4 +123,6 @@
> #define portTICK_RATE_MS ( rtems_clock_get_ticks_per_second() * 1000 )
> #define vTaskDelay( x ) sys_arch_delay( x )
>
> +#include
> +
> #endif /* __LWIPOPTS_H__ */
> diff --git a/rtemslwip/zynqmp_cfc400x/lwipbspopts.h
> b/rtemslwip/zynqmp_cfc400x/lwipbspopts.h
> new file mode 100644
> index 000..27eb6a9
> --- /dev/null
> +++ b/rtemslwip/zynqmp_cfc400x/lwipbspopts.h
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (C) 2022 On-Line Applications Research Corporation (OAR)
> + * Written by Kinsey Moore
> + *
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> +#ifndef RTEMSLWIP_LWIPBSPOPTS_H
> +#define RTEMSLWIP_LWIPBSPOPTS_H
> +
> +/* Use SGMII mode for all interfaces on the CFC-400X */
> +#define ZYNQMP_USE_SGMII
> +
> +#endif /* RTEMSLWIP_LWIPBSPOPTS_H */
> diff --git a/rtemslwip/zynqmp_cfc400x/netstart.c
> b/rtemslwip/zynqmp_cfc400x/netstart.c
> new file mode 100644
> index 000..d19b36c
> --- /dev/null
> +++ b/rtemslwip/zynqmp_cfc400x/netstart.c
> @@ -0,0 +1,66 @@
> +/*
> + * Copyright (C) 2022 On-Line Applications
Re: [PATCH rtems-lwip] rtemslwip: Add note to intentionally blank files
Looks good to me. Do we need copyright statements for these files? On Wed, Nov 9, 2022 at 9:49 PM Kinsey Moore wrote: > > --- > rtemslwip/bsd_compat_include/arpa/nameser.h | 1 + > rtemslwip/bsd_compat_include/machine/rtems-bsd-kernel-space.h | 1 + > rtemslwip/bsd_compat_include/machine/rtems-bsd-user-space.h | 1 + > rtemslwip/bsd_compat_include/net/if_var.h | 1 + > rtemslwip/bsd_compat_include/netinet/in_systm.h | 1 + > rtemslwip/bsd_compat_include/netinet/in_var.h | 1 + > rtemslwip/bsd_compat_include/netinet/ip.h | 1 + > rtemslwip/bsd_compat_include/sys/kernel.h | 1 + > rtemslwip/bsd_compat_include/sysexits.h | 1 + > rtemslwip/include/arch/eth_lwip_default.h | 1 + > rtemslwip/include/bspconfig.h | 1 + > rtemslwip/xilinx/semphr.h | 1 + > rtemslwip/xilinx/timers.h | 1 + > rtemslwip/xilinx/xil_smc.h| 1 + > rtemslwip/xilinx/xil_spinlock.h | 1 + > 15 files changed, 15 insertions(+) > > diff --git a/rtemslwip/bsd_compat_include/arpa/nameser.h > b/rtemslwip/bsd_compat_include/arpa/nameser.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/arpa/nameser.h > +++ b/rtemslwip/bsd_compat_include/arpa/nameser.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/machine/rtems-bsd-kernel-space.h > b/rtemslwip/bsd_compat_include/machine/rtems-bsd-kernel-space.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/machine/rtems-bsd-kernel-space.h > +++ b/rtemslwip/bsd_compat_include/machine/rtems-bsd-kernel-space.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/machine/rtems-bsd-user-space.h > b/rtemslwip/bsd_compat_include/machine/rtems-bsd-user-space.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/machine/rtems-bsd-user-space.h > +++ b/rtemslwip/bsd_compat_include/machine/rtems-bsd-user-space.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/net/if_var.h > b/rtemslwip/bsd_compat_include/net/if_var.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/net/if_var.h > +++ b/rtemslwip/bsd_compat_include/net/if_var.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/netinet/in_systm.h > b/rtemslwip/bsd_compat_include/netinet/in_systm.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/netinet/in_systm.h > +++ b/rtemslwip/bsd_compat_include/netinet/in_systm.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/netinet/in_var.h > b/rtemslwip/bsd_compat_include/netinet/in_var.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/netinet/in_var.h > +++ b/rtemslwip/bsd_compat_include/netinet/in_var.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/netinet/ip.h > b/rtemslwip/bsd_compat_include/netinet/ip.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/netinet/ip.h > +++ b/rtemslwip/bsd_compat_include/netinet/ip.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/sys/kernel.h > b/rtemslwip/bsd_compat_include/sys/kernel.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/sys/kernel.h > +++ b/rtemslwip/bsd_compat_include/sys/kernel.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/bsd_compat_include/sysexits.h > b/rtemslwip/bsd_compat_include/sysexits.h > index e69de29..d35e631 100644 > --- a/rtemslwip/bsd_compat_include/sysexits.h > +++ b/rtemslwip/bsd_compat_include/sysexits.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/include/arch/eth_lwip_default.h > b/rtemslwip/include/arch/eth_lwip_default.h > index e69de29..d35e631 100644 > --- a/rtemslwip/include/arch/eth_lwip_default.h > +++ b/rtemslwip/include/arch/eth_lwip_default.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/include/bspconfig.h b/rtemslwip/include/bspconfig.h > index e69de29..d35e631 100644 > --- a/rtemslwip/include/bspconfig.h > +++ b/rtemslwip/include/bspconfig.h > @@ -0,0 +1 @@ > +/* This file is a stub and intentionally left blank */ > diff --git a/rtemslwip/xilinx/semphr.h b/rtemslwip/xilinx/semphr.h > index e69de29..d35e631 100644 > --- a/rtemslwip/xilinx/semphr.h > +++ b/rtemslwip/xilinx/semphr.h > @@ -0,0 +1 @@ > +/* This file is a stub
Re: [PATCH rtems-lwip v2] lwip.py: Move bsp-specific information out
Thanks for the patch. The v2 looks good. Tested the build with beagleboneblack
On Wed, Nov 9, 2022 at 9:33 PM Kinsey Moore wrote:
>
> This moves all BSP-specific information out of lwip.py and into JSON
> descriptions of the files required to compile the drivers for each BSP.
>
> Note that file-import.json is kept separate because it is used to manage
> updating from upstream.
> ---
> COPYING.defs | 23
> ORIGIN.defs | 1 +
> defs/bsps/aarch64/xilinx_zynqmp_base.json | 30
> .../aarch64/xilinx_zynqmp_ilp32_qemu.json | 11 ++
> .../aarch64/xilinx_zynqmp_ilp32_zu3eg.json| 11 ++
> .../bsps/aarch64/xilinx_zynqmp_lp64_qemu.json | 11 ++
> .../aarch64/xilinx_zynqmp_lp64_zu3eg.json | 11 ++
> defs/bsps/arm/beaglebone_bw_base.json | 10 ++
> defs/bsps/arm/beagleboneblack.json| 5 +
> defs/bsps/arm/beaglebonewhite.json| 5 +
> defs/bsps/arm/tms570_base.json| 9 ++
> defs/bsps/arm/tms570ls3137_hdk.json | 5 +
> defs/bsps/arm/tms570ls3137_hdk_intram.json| 5 +
> defs/bsps/arm/tms570ls3137_hdk_sdram.json | 5 +
> .../arm/tms570ls3137_hdk_with_loader.json | 5 +
> defs/common/lwip.json | 17 +++
> lwip.py | 129 --
> 17 files changed, 194 insertions(+), 99 deletions(-)
> create mode 100644 COPYING.defs
> create mode 100644 ORIGIN.defs
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_base.json
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_ilp32_qemu.json
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_ilp32_zu3eg.json
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_lp64_qemu.json
> create mode 100644 defs/bsps/aarch64/xilinx_zynqmp_lp64_zu3eg.json
> create mode 100644 defs/bsps/arm/beaglebone_bw_base.json
> create mode 100644 defs/bsps/arm/beagleboneblack.json
> create mode 100644 defs/bsps/arm/beaglebonewhite.json
> create mode 100644 defs/bsps/arm/tms570_base.json
> create mode 100644 defs/bsps/arm/tms570ls3137_hdk.json
> create mode 100644 defs/bsps/arm/tms570ls3137_hdk_intram.json
> create mode 100644 defs/bsps/arm/tms570ls3137_hdk_sdram.json
> create mode 100644 defs/bsps/arm/tms570ls3137_hdk_with_loader.json
> create mode 100644 defs/common/lwip.json
>
> diff --git a/COPYING.defs b/COPYING.defs
> new file mode 100644
> index 000..d971823
> --- /dev/null
> +++ b/COPYING.defs
> @@ -0,0 +1,23 @@
> +/*
> + * Redistribution and use in source and binary forms, with or without
> + * modification, are permitted provided that the following conditions
> + * are met:
> + * 1. Redistributions of source code must retain the above copyright
> + *notice, this list of conditions and the following disclaimer.
> + * 2. Redistributions in binary form must reproduce the above copyright
> + *notice, this list of conditions and the following disclaimer in the
> + *documentation and/or other materials provided with the distribution.
> + *
> + * THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS
> IS"
> + * AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
> + * IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
> + * ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
> + * LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
> + * CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
> + * SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> + * ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> + * POSSIBILITY OF SUCH DAMAGE.
> + */
> +
> diff --git a/ORIGIN.defs b/ORIGIN.defs
> new file mode 100644
> index 000..33c421c
> --- /dev/null
> +++ b/ORIGIN.defs
> @@ -0,0 +1 @@
> +The files under the defs/ directory are written specifically for this
> project.
> diff --git a/defs/bsps/aarch64/xilinx_zynqmp_base.json
> b/defs/bsps/aarch64/xilinx_zynqmp_base.json
> new file mode 100644
> index 000..515ad6e
> --- /dev/null
> +++ b/defs/bsps/aarch64/xilinx_zynqmp_base.json
> @@ -0,0 +1,30 @@
> +{
> + "header-paths-to-import": [
> +
> "embeddedsw/ThirdParty/sw_services/lwip211/src/contrib/ports/xilinx/include",
> + "embeddedsw/lib/bsp/standalone/src/common",
> + "embeddedsw/XilinxProcessorIPLib/drivers/common/src/",
> + "embeddedsw/XilinxProcessorIPLib/drivers/scugic/src",
> + "embeddedsw/XilinxProcessorIPLib/drivers/emacps/src",
> + "rtemslwip/xilinx",
> + "rtemslwip/zynqmp",
> + "embeddedsw/lib/bsp/standalone/src/arm/ARMv8/64bit",
> +
Re: [PATCH rtems-lwip 1/2] lwip.py: Remove redundant assignment
Hi Kinsey,
The patches look great. Thanks for the cleanup.
Best regards,
Vijay
On Tue, Nov 1, 2022 at 1:51 PM Kinsey Moore wrote:
>
> ---
> lwip.py | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/lwip.py b/lwip.py
> index c11ed1f..e6580eb 100644
> --- a/lwip.py
> +++ b/lwip.py
> @@ -214,8 +214,6 @@ def build(bld):
> lib=['rtemscpu', 'rtemsbsp', 'rtemstest', 'lwip'],
> includes=' '.join(test_app_incl))
>
> -arch_lib_path = rtems.arch_bsp_lib_path(bld.env.RTEMS_VERSION,
> -bld.env.RTEMS_ARCH_BSP)
> lib_path = os.path.join(bld.env.PREFIX, arch_lib_path)
> bld.read_stlib('telnetd', paths=[lib_path])
> bld.read_stlib('rtemstest', paths=[lib_path])
> --
> 2.30.2
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
Patch pushed. The repository is working, and I see the commit email in vc. Thanks, Vijay On Thu, Jul 21, 2022 at 2:06 PM Vijay Kumar Banerjee wrote: > > I will push this patch. The main intention of this patch is to test > the new top-level repo, but it also provides some essential build > instructions which will certainly be handy. > > On Thu, Jul 21, 2022 at 2:05 PM Vijay Kumar Banerjee wrote: > > > > Hi Kinsey, > > > > thanks for the review > > > > On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore > > wrote: > > > > > > Looks good to me. I never realized that the list of BSPs and tools > > > directory could be omitted if things were installed in particular > > > locations. > > > > > Yes, it picks up all the installed BSPs if there is that option is not > > used. using the BSP argument only builds the mentioned bsps. > > > > > > Best regards, > > Vijay > > > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > > > --- > > > > README | 18 ++ > > > > 1 file changed, 18 insertions(+) > > > > > > > > diff --git a/README b/README > > > > index 91e42ae..99800bf 100644 > > > > --- a/README > > > > +++ b/README > > > > @@ -12,3 +12,21 @@ The sources presented here originate in one of > > > > several locations described by > > > > the ORIGIN.* files and whose license is described by the COPYING.* > > > > files. > > > > Commits adding such files should include the hash of the target > > > > repository if > > > > applicable. > > > > + > > > > +Installation Instructions > > > > +- > > > > +1. Populate the git submodules: > > > > + > > > > +``` > > > > +git submodule init > > > > +git submodule update > > > > +``` > > > > +2. Configure and build > > > > +``` > > > > +./waf configure --prefix=INSTALL_PREFIX > > > > +./waf > > > > +./waf install > > > > +``` > > > > + > > > > +More `waf` arguments can be found by using: > > > > +`./waf --help` > > > ___ > > > devel mailing list > > > devel@rtems.org > > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
I will push this patch. The main intention of this patch is to test the new top-level repo, but it also provides some essential build instructions which will certainly be handy. On Thu, Jul 21, 2022 at 2:05 PM Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > thanks for the review > > On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore wrote: > > > > Looks good to me. I never realized that the list of BSPs and tools > > directory could be omitted if things were installed in particular locations. > > > Yes, it picks up all the installed BSPs if there is that option is not > used. using the BSP argument only builds the mentioned bsps. > > > Best regards, > Vijay > > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > > --- > > > README | 18 ++ > > > 1 file changed, 18 insertions(+) > > > > > > diff --git a/README b/README > > > index 91e42ae..99800bf 100644 > > > --- a/README > > > +++ b/README > > > @@ -12,3 +12,21 @@ The sources presented here originate in one of several > > > locations described by > > > the ORIGIN.* files and whose license is described by the COPYING.* > > > files. > > > Commits adding such files should include the hash of the target > > > repository if > > > applicable. > > > + > > > +Installation Instructions > > > +- > > > +1. Populate the git submodules: > > > + > > > +``` > > > +git submodule init > > > +git submodule update > > > +``` > > > +2. Configure and build > > > +``` > > > +./waf configure --prefix=INSTALL_PREFIX > > > +./waf > > > +./waf install > > > +``` > > > + > > > +More `waf` arguments can be found by using: > > > +`./waf --help` > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] README: Add build instruction
Hi Kinsey, thanks for the review On Thu, Jul 21, 2022 at 1:50 PM Kinsey Moore wrote: > > Looks good to me. I never realized that the list of BSPs and tools > directory could be omitted if things were installed in particular locations. > Yes, it picks up all the installed BSPs if there is that option is not used. using the BSP argument only builds the mentioned bsps. Best regards, Vijay > On 7/21/2022 14:16, Vijay Kumar Banerjee wrote: > > --- > > README | 18 ++ > > 1 file changed, 18 insertions(+) > > > > diff --git a/README b/README > > index 91e42ae..99800bf 100644 > > --- a/README > > +++ b/README > > @@ -12,3 +12,21 @@ The sources presented here originate in one of several > > locations described by > > the ORIGIN.* files and whose license is described by the COPYING.* files. > > Commits adding such files should include the hash of the target > > repository if > > applicable. > > + > > +Installation Instructions > > +- > > +1. Populate the git submodules: > > + > > +``` > > +git submodule init > > +git submodule update > > +``` > > +2. Configure and build > > +``` > > +./waf configure --prefix=INSTALL_PREFIX > > +./waf > > +./waf install > > +``` > > + > > +More `waf` arguments can be found by using: > > +`./waf --help` > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-lwip] README: Add build instruction
--- README | 18 ++ 1 file changed, 18 insertions(+) diff --git a/README b/README index 91e42ae..99800bf 100644 --- a/README +++ b/README @@ -12,3 +12,21 @@ The sources presented here originate in one of several locations described by the ORIGIN.* files and whose license is described by the COPYING.* files. Commits adding such files should include the hash of the target repository if applicable. + +Installation Instructions +- +1. Populate the git submodules: + +``` +git submodule init +git submodule update +``` +2. Configure and build +``` +./waf configure --prefix=INSTALL_PREFIX +./waf +./waf install +``` + +More `waf` arguments can be found by using: +`./waf --help` -- 2.34.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Time to promote lwip git repo
Thank you everyone for supporting the move! On Tue, Jul 19, 2022 at 3:24 PM Chris Johns wrote: > > Thanks to everyone for this effort. > > Vijay, if you need a hand doing this please ping me on discord. I have moved it to the top level and added the hooks using the doc I wrote last time: https://docs.rtems.org/branches/master/eng/vc-authors.html#migrate-a-personal-repository-to-top-level > > Chris > > On 20/7/2022 12:40 am, Gedare Bloom wrote: > > On Wed, Jul 13, 2022 at 11:27 PM Christian MAUDERER > > wrote: > >> > >> Am 13.07.22 um 04:51 schrieb Chris Johns: > >>> On 13/7/2022 10:08 am, Joel Sherrill wrote: > Vijay and Kinsey have made great progress in addressing the issues that > were > raised about the lwip tcpip stack that needed to be addressed before it > became > an official top level repository. Thanks to both of them. > >>> > >>> Well done. Great effort. > >>> > I think it's time to promote the repo. Hopefully just a couple of core > developers agreeing is sufficient to get this moving. > >>> > >>> I support this happening. It is great to see this networking option for > >>> small > >>> devices become available. > >> > >> I haven't tested the lwip repository yet, but I agree that a stack for > >> small targets is great. So I would support that too. > >> > > I'm glad to see this happening and support the promotion. > > > >> Christian > >> -- > >> > >> embedded brains GmbH > >> Herr Christian MAUDERER > >> Dornierstr. 4 > >> 82178 Puchheim > >> Germany > >> email: christian.maude...@embedded-brains.de > >> phone: +49-89-18 94 741 - 18 > >> mobile: +49-176-152 206 08 > >> > >> Registergericht: Amtsgericht München > >> Registernummer: HRB 157899 > >> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > >> Unsere Datenschutzerklärung finden Sie hier: > >> https://embedded-brains.de/datenschutzerklaerung/ > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP
Hi, On Fri, Jul 1, 2022 at 9:20 PM Vijay Kumar Banerjee wrote: > > On Fri, Jul 1, 2022 at 8:19 PM Kinsey Moore wrote: > > > > On 7/1/2022 18:50, Vijay Kumar Banerjee wrote: > > > > On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee wrote: > > > > Hi Kinsey, > > > > This patchset is looking great. Thank you! > > Unfortunately, I won't be able to test the BBB right away but I see > > that most patches are probably from the devel branch of lwip, which I > > > > correction: most of BBB related changes. :) > > > > It should actually be all of the BBB related changes, I just squashed some > > of them together since I was doing a pretty heavy rework anyway. > > Makes sense. > > > > > > You mentioned on Discord that a couple of the patches didn't make it > > through. You can find the entire patch set on top of main here: > > > > https://github.com/KinseyMoore/rtems-lwip I pushed the latest patches from this repository. Thanks for the patches. Best, Vijay > > Thanks for posting the repo link. > > > Best regards, > Vijay > > > > Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP
On Fri, Jul 1, 2022 at 8:19 PM Kinsey Moore wrote: > > On 7/1/2022 18:50, Vijay Kumar Banerjee wrote: > > On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > This patchset is looking great. Thank you! > Unfortunately, I won't be able to test the BBB right away but I see > that most patches are probably from the devel branch of lwip, which I > > correction: most of BBB related changes. :) > > It should actually be all of the BBB related changes, I just squashed some of > them together since I was doing a pretty heavy rework anyway. Makes sense. > > > You mentioned on Discord that a couple of the patches didn't make it through. > You can find the entire patch set on top of main here: > > https://github.com/KinseyMoore/rtems-lwip Thanks for posting the repo link. Best regards, Vijay > > Kinsey ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP
On Fri, Jul 1, 2022 at 5:49 PM Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > This patchset is looking great. Thank you! > Unfortunately, I won't be able to test the BBB right away but I see > that most patches are probably from the devel branch of lwip, which I correction: most of BBB related changes. :) > tested before. I am going to wait till Tuesday, to get any comments or > objections from others. If no changes are required, I will push these > patches on Tuesday. > > Best regards, > Vijay > > > On Fri, Jul 1, 2022 at 4:32 PM Kinsey Moore wrote: > > > > This brings in a significantly cleaned up version of the remaining > > patches on the devel branch and adds support for ZynqMP CGEMs. I have > > tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the > > BeagleBoneBlack at the moment, so I'd appreciate a double-check to > > ensure I haven't broken it. > > > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip v1 0/9] Bring in devel patches and add ZynqMP
Hi Kinsey, This patchset is looking great. Thank you! Unfortunately, I won't be able to test the BBB right away but I see that most patches are probably from the devel branch of lwip, which I tested before. I am going to wait till Tuesday, to get any comments or objections from others. If no changes are required, I will push these patches on Tuesday. Best regards, Vijay On Fri, Jul 1, 2022 at 4:32 PM Kinsey Moore wrote: > > This brings in a significantly cleaned up version of the remaining > patches on the devel branch and adds support for ZynqMP CGEMs. I have > tested CGEM0 on QEMU and CGEM3 on hardware. I am unable to test on the > BeagleBoneBlack at the moment, so I'd appreciate a double-check to > ensure I haven't broken it. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Congratulations to Two Core Developers
Congratulations, Gedare and Hesham! I had the honor and privilege of working with both of you, and your knowledge and passion have been a true inspiration to me. Best, Vijay On Tue, Jun 28, 2022 at 8:23 AM Joel Sherrill wrote: > > Hi > > I'd like to congratulate two RTEMS core developers on recent significant > achievements. > > (1) Gedare Bloom was granted tenure at the University of Colorado at Colorado > Springs. > > (2) Hesham Almatary has passed his Ph.D. viva/orals and is nearing graduation. > > These are both major life events and the RTEMS Community would like to > congratulate them. > > --joel > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Pavel, On Thu, Jun 2, 2022 at 12:09 AM Pavel Pisa 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
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hello everyone,
I have pushed this patch and I would like to add a note regarding that.
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, but for now, I pushed the patch so
that Kinsey can continue working on other patches. There is also a
discussion on the included licenses. I believe that the approach in
that direction will also mature as we keep bringing new patches and
involve the wider community.
Thank you to everyone for providing valuable feedback.
Best regards,
Vijay
On Tue, May 31, 2022 at 8:04 PM Vijay Kumar Banerjee wrote:
>
> On Tue, May 31, 2022 at 3:13 PM Kinsey Moore wrote:
> >
> > On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa
> > > wrote:
> > >> Hello Joel,
> > >>
> > >> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> > >>> Ok. Any suggestions for a directory name? :)
> > >> I am not in the full sync and I have lost the tracks where
> > >> are all RTEMS LwIP repo copies.
> > >>
> > >> Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
> > >>
> > > Yes
> > Given that a better directory name doesn't appear to be forthcoming, is
> > there anything else preventing this patch from going in as a starting
> > point to further improvements?
> > >
> > >> If it is that way then LwIP uses practice to put integration
> > >> stuff into "ports" directory so I would leave the structure
> > >> under LwIP as it is
> > >>
> > >>ports/os/rtems/arch/sys_arch.c
> > >>
> > >> Or if you want to somehow separate sources into more repos
> > >> then possible but would complicate keep the drivers and targets
> > >> in a sync in future. I am losing tracks of the build tools etc...
> > >> I hope that when it settles the simple instructions
> > >> would be added on the integration page
> > >>
> > >>https://devel.rtems.org/wiki/Packages/LWIP
> > >>
> > >> If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
> > >> then it should be something like
> > >>
> > >>rtems-support/ports/os/rtems/arch/sys_arch.c
> > >>
> > > This would be a good idea. We can put all RTEMS-related ports into a
> > > separate directory. If there's any driver-specific port, that can also
> > > be added there and waf can be taught to pick up the right one
> > > according to the target.
> > I'm about to start some additional work for lwIP support on ZynqMP. I'll
> > see about breaking any code written specifically by RTEMS developers
> > (just Vijay at this point) into a rtemslwip directory (similar to
> > rtemsbsd in rtems-libbsd).
>
> I will push this into the repository so that we can keep working on it
> incrementally.
>
> Thank you.
> > >
> > >> if the code can be used over all RTEMS targets. Which should be
> > >> a goal anyway and I have initiated it such way years ago.
> > >> But I am not sure why to not let code in the actual
> > >> lwip/ports/drivers together as well. I see that
> > >> in devel branch is the most of our TMS570 code wiped
> > >> out... hmm.. why. There is
> > >>
> > >> lwip/ports/drivers/bbb
> > >>
> > >> this location seems to me as OK.
> > >> In the suggested changes is
> > >>
> > >> {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> > >>
> > >> I agree with move of all TMS570 specific code under
> > >>
> > >>/ports/driver/tms570_emac
> > >>
> > > I agree with this approach, as it allows adding sources with
> > > problematic license (like STM) into its own directory and a warning
> > > can be added to waf while building those targets.
> > >
> > >> Again if all these shuffles are done only for some license changes
> > >> I would prefer to be noticed and I think that I would not be blocked
> > >> by any of my former studnets nor the faculty to relicense code.
> > >> I would inform the faculty (where I am only left from former group,
> > >> where I
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Tue, May 31, 2022 at 3:13 PM Kinsey Moore wrote:
>
> On 5/12/2022 16:30, Vijay Kumar Banerjee wrote:
> > On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa wrote:
> >> Hello Joel,
> >>
> >> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> >>> Ok. Any suggestions for a directory name? :)
> >> I am not in the full sync and I have lost the tracks where
> >> are all RTEMS LwIP repo copies.
> >>
> >> Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
> >>
> > Yes
> Given that a better directory name doesn't appear to be forthcoming, is
> there anything else preventing this patch from going in as a starting
> point to further improvements?
> >
> >> If it is that way then LwIP uses practice to put integration
> >> stuff into "ports" directory so I would leave the structure
> >> under LwIP as it is
> >>
> >>ports/os/rtems/arch/sys_arch.c
> >>
> >> Or if you want to somehow separate sources into more repos
> >> then possible but would complicate keep the drivers and targets
> >> in a sync in future. I am losing tracks of the build tools etc...
> >> I hope that when it settles the simple instructions
> >> would be added on the integration page
> >>
> >>https://devel.rtems.org/wiki/Packages/LWIP
> >>
> >> If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
> >> then it should be something like
> >>
> >>rtems-support/ports/os/rtems/arch/sys_arch.c
> >>
> > This would be a good idea. We can put all RTEMS-related ports into a
> > separate directory. If there's any driver-specific port, that can also
> > be added there and waf can be taught to pick up the right one
> > according to the target.
> I'm about to start some additional work for lwIP support on ZynqMP. I'll
> see about breaking any code written specifically by RTEMS developers
> (just Vijay at this point) into a rtemslwip directory (similar to
> rtemsbsd in rtems-libbsd).
I will push this into the repository so that we can keep working on it
incrementally.
Thank you.
> >
> >> if the code can be used over all RTEMS targets. Which should be
> >> a goal anyway and I have initiated it such way years ago.
> >> But I am not sure why to not let code in the actual
> >> lwip/ports/drivers together as well. I see that
> >> in devel branch is the most of our TMS570 code wiped
> >> out... hmm.. why. There is
> >>
> >> lwip/ports/drivers/bbb
> >>
> >> this location seems to me as OK.
> >> In the suggested changes is
> >>
> >> {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> >>
> >> I agree with move of all TMS570 specific code under
> >>
> >>/ports/driver/tms570_emac
> >>
> > I agree with this approach, as it allows adding sources with
> > problematic license (like STM) into its own directory and a warning
> > can be added to waf while building those targets.
> >
> >> Again if all these shuffles are done only for some license changes
> >> I would prefer to be noticed and I think that I would not be blocked
> >> by any of my former studnets nor the faculty to relicense code.
> >> I would inform the faculty (where I am only left from former group,
> >> where I have lead part of this development, part was at my company)
> >> as well as students.
> >>
> >> I would prefer if real developer names who invested time into work
> >> are included at least as Authors in the files but the copyright can
> >> be moved to RTEMS foundation or whatever.
> >>
> >> But as I have said I have lost track and hope that stuff will survive
> >> in some form till the time when I have some free time or studnet
> >> to work on the project as his/her theses, GSoC etc...
> >> I have used the code with external OMK make, I agree that this
> >> is not right way forward but I wait for outcome of these who
> >> have more experience with RSB and related tools and propose
> >> integration.
>
> As long as the code is licensed appropriately for inclusion in this
> project, I see no reason to relicense it under most conditions.
>
>
> Kinsey
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
On Sat, Apr 16, 2022 at 10:48 AM Pavel Pisa wrote:
>
> Hello Joel,
>
> On Saturday 16 of April 2022 17:26:02 Joel Sherrill wrote:
> > On Sat, Apr 16, 2022, 9:54 AM Pavel Pisa wrote:
> > > On Thursday 14 of April 2022 22:08:00 Vijay Kumar Banerjee wrote:
> > > > rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> > > >
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> > > > > rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
> >
> > Ok. Any suggestions for a directory name? :)
>
> I am not in the full sync and I have lost the tracks where
> are all RTEMS LwIP repo copies.
>
> Do we speak about https://git.rtems.org/vijay/rtems-lwip.git ?
>
Yes
> If it is that way then LwIP uses practice to put integration
> stuff into "ports" directory so I would leave the structure
> under LwIP as it is
>
> ports/os/rtems/arch/sys_arch.c
>
> Or if you want to somehow separate sources into more repos
> then possible but would complicate keep the drivers and targets
> in a sync in future. I am losing tracks of the build tools etc...
> I hope that when it settles the simple instructions
> would be added on the integration page
>
> https://devel.rtems.org/wiki/Packages/LWIP
>
> If you need to move ports/os/rtems/arch/sys_arch.c under some directory,
> then it should be something like
>
> rtems-support/ports/os/rtems/arch/sys_arch.c
>
This would be a good idea. We can put all RTEMS-related ports into a
separate directory. If there's any driver-specific port, that can also
be added there and waf can be taught to pick up the right one
according to the target.
> if the code can be used over all RTEMS targets. Which should be
> a goal anyway and I have initiated it such way years ago.
> But I am not sure why to not let code in the actual
> lwip/ports/drivers together as well. I see that
> in devel branch is the most of our TMS570 code wiped
> out... hmm.. why. There is
>
> lwip/ports/drivers/bbb
>
> this location seems to me as OK.
> In the suggested changes is
>
> {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
>
> I agree with move of all TMS570 specific code under
>
> /ports/driver/tms570_emac
>
I agree with this approach, as it allows adding sources with
problematic license (like STM) into its own directory and a warning
can be added to waf while building those targets.
> Again if all these shuffles are done only for some license changes
> I would prefer to be noticed and I think that I would not be blocked
> by any of my former studnets nor the faculty to relicense code.
> I would inform the faculty (where I am only left from former group,
> where I have lead part of this development, part was at my company)
> as well as students.
>
> I would prefer if real developer names who invested time into work
> are included at least as Authors in the files but the copyright can
> be moved to RTEMS foundation or whatever.
>
> But as I have said I have lost track and hope that stuff will survive
> in some form till the time when I have some free time or studnet
> to work on the project as his/her theses, GSoC etc...
> I have used the code with external OMK make, I agree that this
> is not right way forward but I wait for outcome of these who
> have more experience with RSB and related tools and propose
> integration.
>
> Best wishes,
>
> Pavel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-lwip] lwip: Split sources into origin directories
Hi Kinsey,
Thank you for sorting this out. I will merge it on Monday if no one objects.
Best regards,
Vijay
On Thu, Apr 14, 2022 at 11:33 AM Kinsey Moore wrote:
>
> Moving forward, each origin directory should have its own top-level
> COPYING.origin file to describe its license as well as a ORIGIN.origin
> file to describe where the code is sourced from.
> ---
> COPYING.lwip | 25 ++
> COPYING.uLan | 33 +++
> ORIGIN.lwip | 2 ++
> ORIGIN.uLan | 2 ++
> README| 14
> lwip.py | 10 +++---
> .../ports/driver/tms570_emac}/eth_lwip.c | 0
> .../ports/driver/tms570_emac}/eth_lwip.h | 0
> .../driver/tms570_emac}/eth_lwip_default.h| 0
> .../ports/driver/tms570_emac}/phy_dp83848h.c | 0
> .../ports/driver/tms570_emac}/phy_dp83848h.h | 0
> .../ports/driver/tms570_emac}/ti_drv_emac.h | 0
> .../ports/driver/tms570_emac}/ti_drv_mdio.h | 0
> .../ports/driver/tms570_emac}/tms570_emac.h | 0
> .../ports/driver/tms570_emac}/tms570_netif.c | 0
> .../ports/driver/tms570_emac}/tms570_netif.h | 0
> {lwip => uLan}/ports/os/lwipopts.h| 0
> {lwip => uLan}/ports/os/rtems/arch/cc.h | 0
> {lwip => uLan}/ports/os/rtems/arch/perf.h | 0
> {lwip => uLan}/ports/os/rtems/arch/sys_arch.c | 0
> {lwip => uLan}/ports/os/rtems/arch/sys_arch.h | 0
> 21 files changed, 81 insertions(+), 5 deletions(-)
> create mode 100644 COPYING.lwip
> create mode 100644 COPYING.uLan
> create mode 100644 ORIGIN.lwip
> create mode 100644 ORIGIN.uLan
> create mode 100644 README
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/eth_lwip.h
> (100%)
> rename {lwip/ports/drivers =>
> uLan/ports/driver/tms570_emac}/eth_lwip_default.h (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/phy_dp83848h.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_emac.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/ti_drv_mdio.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_emac.h
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.c
> (100%)
> rename {lwip/ports/drivers => uLan/ports/driver/tms570_emac}/tms570_netif.h
> (100%)
> rename {lwip => uLan}/ports/os/lwipopts.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/cc.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/perf.h (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.c (100%)
> rename {lwip => uLan}/ports/os/rtems/arch/sys_arch.h (100%)
>
> diff --git a/COPYING.lwip b/COPYING.lwip
> new file mode 100644
> index 000..90465f5
> --- /dev/null
> +++ b/COPYING.lwip
> @@ -0,0 +1,25 @@
> +Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> +All rights reserved.
> +
> +Redistribution and use in source and binary forms, with or without
> modification,
> +are permitted provided that the following conditions are met:
> +
> +1. Redistributions of source code must retain the above copyright notice,
> + this list of conditions and the following disclaimer.
> +2. Redistributions in binary form must reproduce the above copyright notice,
> + this list of conditions and the following disclaimer in the documentation
> + and/or other materials provided with the distribution.
> +3. The name of the author may not be used to endorse or promote products
> + derived from this software without specific prior written permission.
> +
> +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED
> +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
> +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO
> EVENT
> +SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
> +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
> PROCUREMENT
> +OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
> +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
> +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
> ARISING
> +IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
> POSSIBILITY
> +OF SUCH DAMAGE.
> +
> diff --git a/COPYING.uLan b/COPYING.uLan
> new file mode 100644
> index 000..e23898b
> --- /dev/null
> +++ b/COPYING.uLan
> @@ -0,0 +1,33 @@
> +/*
> + * Copyright (c) 2001, 2002 Swedish Institute of Computer Science.
> + * All rights reserved.
> + *
> + * Redistribution and use in source and binary forms, with or without
> modification,
> + * are permitted provided
Re: [PATCH rtems-lwip] Add missing COPYING files from lwip and uLan
Hi Kinsey, Thanks for the patch. I was wondering if it would be a good idea to use this patch and add a comment in the respective source files that they are based on an external repository and the related copying files are COPYING.something ? On Fri, Mar 4, 2022 at 7:49 AM Kinsey Moore wrote: > > These are the original COPYING files from the upstream projects. > --- > COPYING.lwip | 25 + > COPYING.uLan | 33 + > 2 files changed, 58 insertions(+) > create mode 100644 COPYING.lwip > create mode 100644 COPYING.uLan > > diff --git a/COPYING.lwip b/COPYING.lwip > new file mode 100644 > index 000..90465f5 > --- /dev/null > +++ b/COPYING.lwip > @@ -0,0 +1,25 @@ > +Copyright (c) 2001, 2002 Swedish Institute of Computer Science. > +All rights reserved. > + > +Redistribution and use in source and binary forms, with or without > modification, > +are permitted provided that the following conditions are met: > + > +1. Redistributions of source code must retain the above copyright notice, > + this list of conditions and the following disclaimer. > +2. Redistributions in binary form must reproduce the above copyright notice, > + this list of conditions and the following disclaimer in the documentation > + and/or other materials provided with the distribution. > +3. The name of the author may not be used to endorse or promote products > + derived from this software without specific prior written permission. > + > +THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR IMPLIED > +WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > +MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO > EVENT > +SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, > +EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, > PROCUREMENT > +OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS > +INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > +CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > ARISING > +IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > POSSIBILITY > +OF SUCH DAMAGE. > + > diff --git a/COPYING.uLan b/COPYING.uLan > new file mode 100644 > index 000..e23898b > --- /dev/null > +++ b/COPYING.uLan > @@ -0,0 +1,33 @@ > +/* > + * Copyright (c) 2001, 2002 Swedish Institute of Computer Science. > + * All rights reserved. > + * > + * Redistribution and use in source and binary forms, with or without > modification, > + * are permitted provided that the following conditions are met: > + * > + * 1. Redistributions of source code must retain the above copyright notice, > + *this list of conditions and the following disclaimer. > + * 2. Redistributions in binary form must reproduce the above copyright > notice, > + *this list of conditions and the following disclaimer in the > documentation > + *and/or other materials provided with the distribution. > + * 3. The name of the author may not be used to endorse or promote products > + *derived from this software without specific prior written permission. > + * > + * THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS'' AND ANY EXPRESS OR > IMPLIED > + * WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF > + * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN > NO EVENT > + * SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, > + * EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, > PROCUREMENT > + * OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR > BUSINESS > + * INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN > + * CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) > ARISING > + * IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE > POSSIBILITY > + * OF SUCH DAMAGE. > + * > + * This file is part of the lwIP TCP/IP stack. > + * > + * Author: Adam Dunkels > + * > + */ > + > + > -- > 2.30.2 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: rtems-lwip file locations and licensing
Hi Kinsey, On Fri, Mar 4, 2022 at 9:47 AM Kinsey Moore wrote: > > I was looking though the rtems-lwip tree in adding license files and it > struck me that we currently have code with possibly different licenses and > from different external sources merged into the same tree with possibly > differing paths from the original source locations. There is at least one > file in the uLan sources that does not have an embedded license and the > current setup makes discerning its license confusing. I could add what I > think is the correct license, but I'd much prefer not to add licenses to the > code given that I'm not the author. > > That said, I'd like to suggest that we keep code from each external source in > its own directory. Currently, the external sources are upstream lwIP and the > uLan projects with their code being merged into a single tree with some > changes to the location of uLan's files. My suggestion would move all uLan > code to a uLan/ directory in the root of the rtems-lwip repository and each > COPYING. license file as well. Each new driver source would get its > own directory and COPYING file in the root of the repository as necessary. > Sounds like a very reasonable approach and we can move the sources according to the source of drivers. We might have to keep a list of all directories in the waf, to keep the build system working. The reason for keeping the files in one place was to have a similar structure as the net-legacy. We can use a directory structure according to the sources, but we will have to use a good way to make sure that the directories/source files are easier to navigate for humans and build system scripts. > Thanks, > Kinsey > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3 2/2] update README with instructions for stm32 patch
Hi Robin, Looks like this patch answers one of my questions in the other patch. This looks good and can be merged after the first patch. Thanks! On Sun, Oct 24, 2021 at 4:59 AM Robin Müller wrote: > > Hi, > > This patch now contains all files which have the problematic license so the > RTMES LwIP code stays free of them. > Actually, it probably would be a better idea if the patch is applied as > part of the build process.. Does anyone have experience how to do this with > waf? > > Kind Regards > Robin Müller > > On Sun, 24 Oct 2021 at 12:54, Robin Mueller > wrote: > > > --- > > README.md | 10 ++ > > 1 file changed, 10 insertions(+) > > > > diff --git a/README.md b/README.md > > index ebbef12..3653b67 100644 > > --- a/README.md > > +++ b/README.md > > @@ -17,6 +17,16 @@ It is recommended that the user supplies the > > `lwipopts.h` configuration file. Th > > contain template option files to get started. The user can copy and > > rename this files into the > > application and then pass the include path to the build system using the > > `--lwip-opts` option. > > > > +# Applying the STM32 patch file > > + > > +Some STM32 files are problematic due to the used license. Therefore, they > > are applied in form of > > +a patch. You need to perform the following steps in order to use the > > STM32H7 BSP: > > + > > +```sh > > +wget -O stm32.patch > > https://raw.githubusercontent.com/robamu-org/rtems-stm32-lwip-port-patch/main/stm32-bsp-eth-dhcp-files.patch > > +git am stm32.patch > > +``` > > + > > # Building with waf > > > > It is assumed that the path(s) containing the `lwipopts.h` file was > > stored in the environmental > > -- > > 2.32.0 > > > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-libbsd 0/5] RTEMS LibBSD Documentation
On Mon, Aug 2, 2021 at 10:11 AM Gedare Bloom wrote: > > On Mon, Aug 2, 2021 at 7:03 AM Christian MAUDERER > wrote: > > > > Am 02.08.21 um 10:38 schrieb Chris Johns: > > > On 2/8/21 4:58 pm, Christian MAUDERER wrote: > > >> Hello Husni, > > >> > > >> thanks for the patches. I'm sure that this will start a discussion about > > >> the > > >> right place for that documentation. libbsd documentation is a long > > >> overdue topic > > >> that has been neglected by all of us (including myself) so I think it's > > >> good to > > >> start that discussion. > > > > > > I suggest the user manual. > > > > > > Chris > > > > > > > Hello Chris, > > > > thanks for the suggestion. So that would be a new libbsd chapter in the > > user manual and not some extra manual like the "Legacy Networking User > > Manual"? > > > @Vijay Kumar Banerjee would you anticipate a new networking manual, or > just a networking subsection in the user manual? Libbsd encompasses > more than just networking, so it might be sensible to give libbsd its > own entire subsection. Then, lwIP could also get a subsection in the > future? > I think there should be a high-level user manual subsection for networking that describes how the selection of the network stack works. We can then add another subsection about lwip since legacy already has one, and libbsd is getting added now. > > Sooner or later most of the user facing documentation we already have in > > libbsd most likely would be moved there too. That would be mainly: > > > > https://git.rtems.org/rtems-libbsd/tree/README.md > > https://git.rtems.org/rtems-libbsd/tree/libbsd.txt > > > > The CONTRIBUTING.md is more developer facing. Would we move that in the > > user manual too or would that be something that should move to either > > "BSP and Driver Guide" or the "Software Engineering" manual: > > > Developer-facing would be moved probably to both BSP and SwE manuals, > depending on the content. BSP manual requires a refresh itself, but is > the right place to add guidance how to port/implement the libbsd > drivers. SwE manual is the right place to document the rules to > contribute to libbsd. > > > https://git.rtems.org/rtems-libbsd/tree/CONTRIBUTING.md > > > > Note that I don't want to push that work to anyone. I asked Husni that > > he adds his work to a new manual at the moment so that we have a basis > > for discussion. The alternative would be to continue adding information > > like that to the text documents in libbsd. But the text files start to > > get convoluted and I think a better organized manual is long overdue. I > > thought that Husnis work would be a great chance to trigger finding the > > right place so that we can add or move more documentation to that place > > slowly. I'm sure that I should do quite some of that too because I have > > added a lot of stuff to libbsd over the time. > > > > Best regards > > > > Christian > > -- > > > > embedded brains GmbH > > Herr Christian MAUDERER > > Dornierstr. 4 > > 82178 Puchheim > > Germany > > email: christian.maude...@embedded-brains.de > > phone: +49-89-18 94 741 - 18 > > fax: +49-89-18 94 741 - 08 > > > > Registergericht: Amtsgericht München > > Registernummer: HRB 157899 > > Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler > > Unsere Datenschutzerklärung finden Sie hier: > > https://embedded-brains.de/datenschutzerklaerung/ > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi all, On Thu, Jul 22, 2021 at 4:12 PM Pavel Pisa wrote: > > Hello Joel, > > On Thursday 22 of July 2021 22:19:21 Joel Sherrill wrote: > > On Thu, Jul 22, 2021 at 12:25 PM Robin Müller > > > The current version of the rtems-lwip support after I added STM32H7 can > > > still be found here: > > > https://github.com/rmspacefish/rtems-lwip/tree/mueller/master and > > > includes the TMS570 code as well. > > > > > > There is also a LPC port here: > > > https://github.com/sacha23/lwip-rtems-support/tree/master/src/ports/drive > > >r/lpc_emac But that one still appears to use Makefiles, and needs to be > > > updated to waf if it is integrated. > > > > Very nice. Updating to waf should be a lot easier than writing the driver. > > :) > > > > Vijay.. it's your call but if adding drivers with status of "compile > > only" is OK with you, that at least lays the groundwork for someone > > else to test later. I'm just thinking that compiles and untested makes > > it easy for someone to push it across the goal line. > > That is surprise, I forgot that port of our sysless LPC driver to RTEMS > exists. The code in sysless mode is used by Alvat company http://alvat.cz/ > (founded by our alumni Pavel Nemecek ) to provide Pick to Light system > gateway and embedded web on LPC. Our robotic control systems LX_RoCoN > use it in daily operation in selfbuild interferometer of Czech Academy > of Sciences aspherical lens production etc. So the core of the driver > should be functional. I have newer used it on RTEMS but I have > there LX_RoCoN running on table before me exactly now. Not > with RTEMS, but I have tested RTEMS on it, so I can give it > a try if I learn again WAF stuff. > This is amazing! I can help with the waf integration. I'm working on making the waf system in rtems-lwip better, so that it doesn't take much effort to integrate a new set of drivers like this. > I am adding Roman Bartosnsky to CC, he is main author > of LPC driver and LwIP OMK port done under my company > funding and then on some Alvat budget. He woks on more > ESA projects at his company https://www.daiteq.com/ , > an actual one is NOEL-V related. He worked with me for years > on our RTEMS based medical infusion systems, so he knew > RTEMS and CPU architectures well. > Great! It would be great to get it tested on a hardware after it's ported on rtems-lwip. > So there are people who have strong insight into the code. > So if it has been located again it would worth to collect > in on one place. We have some enhancements of the LPC > driver in our OMK repo, so we can merge updates. > I expect that they do not collide with changes for > RTEMS build. > I'm following the OMK repository for TMS570. After the waf support is added with the STM32 and LPC, It should be possible to merge the driver updates from omk. Best regards, Vijay > Best wishes, > > Pavel Pisa > > == > PiKRON s.r.o. Phone/Fax: +420 284684676 > Kankovskeho 1235Phone: +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
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi, On Wed, Jul 21, 2021 at 2:25 AM Pavel Pisa wrote: > > Hello Vijay, > > thanks of the status. > I added a note in the devel page: https://devel.rtems.org/wiki/Packages/LWIP > On Wednesday 21 of July 2021 07:16:51 Vijay Kumar Banerjee wrote: > > Hi Pavel, > > > > On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa wrote: > > > Is it devel branch of Vijay Kumar Banerjee's > > > repo > > > > > > https://git.rtems.org/vijay/rtems-lwip.git/ > > > > Right now yes. Once this is mature, it will probably be pushed to the > > top directory. > > > > > If so, it would worth to put that on the top > > > of LwIP RTEMS info page to guide people interested > > > to live work and not lose time in another > > > abandonned attempts > > > > > > https://devel.rtems.org/wiki/Packages/LWIP > > > > Thanks, I'll add a note there. > > > > > Addition of pointers to STM WIP to some > > > central place would worth too with > > > pointer to the instructions or instructions > > > included... > > > > I haven't tested it myself. Robin is working on this one and might be > > able to add the instructions. But this is supposed to be merged into > > the repo you mentioned above. > > Great that there is the common merge place. > > > > > Generally I am curious what works and where > > > are problems. I do not expect to have time or > > > find students this summer but I try to offer > > > project as theses and next summer and there > > > chance (small) that I find some studnet > > > to participate. > > > > I am currently actively working on the lwip port to get it working > > with at least a few boards, along with a streamlined build system. I > > could only get the BBB running with a telnetd application that I added > > in the test/ directory in the rtems-lwip repository. I used the > > drivers from TI for BBB. > > OK, I have some access to BBB so when my or some studnet > time allows we can test it on this target. Thanks. Any feedback would be really appreciated. > I am more personally interested to TMS570. > I think that I can find some time for testing on TMS570LS3137 > if the instructions and code is declared to worth to test. > I hope that I have all tools for this setup. > This has not been tested yet, I'm working on the build system to streamline the process further. It would be great to get this port tested. Please ping me if you have any build issues when testing (if you happen to test before the build system update :) ). > = > Side note to TMS570 FEE CTU code (if there is interest, > I it would worth to move to separate thread) > > By the way, the way my former colleagues who left faculty > stopped blocking (after many years) TMS570 Rapid Prototyping > Platform code > http://rtime.felk.cvut.cz/rpp-tms570/ > and changed master branch license to MIT (The work has been > exploited to gain money from their industrial partners and has > little value for them now). Code was and is licensed under our > faculty name and I can legally show it to third parties now > and try to find arrangement to share my and my students effort > with community. > > There is XCP https://en.wikipedia.org/wiki/XCP_(protocol) > loader implemented on FreeRTOS base which allows to update > firmware over ETHERNET so it can be used as boot block for > RTEMS. It can make RTEMS support testing and even continuous > integration much easier. When RTEMS is run from SDRAM it > would prevent Flash wear-out, important for TMS570, > because guaranteed erase cycles are limited. > > Then there is support for lot of the TMS570 peripherals > in the state twisted with HalCoGen, not directly usable, > but valuable as reference. Lot of Matlab/Simulink glue > which can be reused with minimal changes and N2HET and > DMA based "HW" implementation of time triggered CAN > transfers with clock scaling and synchronization. > > So if there is interest, I can provide more information > and collect it in RTEMS Wiki or on > > Open Technologies Research Education and Exchange Services > https://gitlab.fel.cvut.cz/otrees/org/-/wikis/home > > pages, which are intended primarily for cooperation with > our students. > > As for original RTIME wiki and documentation (even documenting > RTEMS and GNU/Linux work shared from my company, done with studnets, > myself at home), I do not expect to contribute to it any more. > Even that substantial part is result of my 25 years of investent > to that group but its leaders took it with t
Re: LwIP for RTEMS state querry Was: [PATCH rtems-lwip v2] STM32 lwIP addition
Hi Pavel, On Tue, Jul 20, 2021 at 1:13 PM Pavel Pisa wrote: > > Hello everybody, > > I have no technical stuff to share for now, > but I am happy that work on LwIP alternative > stack for RTEMS continues on. > > I have question which repo is considered as > mainline (integration point) for this work. > Is it devel branch of Vijay Kumar Banerjee's > repo > > https://git.rtems.org/vijay/rtems-lwip.git/ > Right now yes. Once this is mature, it will probably be pushed to the top directory. > If so, it would worth to put that on the top > of LwIP RTEMS info page to guide people interested > to live work and not lose time in another > abandonned attempts > > https://devel.rtems.org/wiki/Packages/LWIP > Thanks, I'll add a note there. > Addition of pointers to STM WIP to some > central place would worth too with > pointer to the instructions or instructions > included... > I haven't tested it myself. Robin is working on this one and might be able to add the instructions. But this is supposed to be merged into the repo you mentioned above. > In the longer term horizon, it would worth > to get rid of twisted translation layer I have > introduced initially > > > https://git.rtems.org/vijay/rtems-lwip.git/tree/lwip/src/api/rtems_lwip_sysdefs.c?h=devel > > The best option would be if mainline LwIP provides > configurable option to use external types, enums, > structures (struct sockaddr) prototypes from libc > (i.e. NewLib) which would remove this translation. > I still think that move to LWIP_NETCONN only > and disable of LWIP_SOCKET could be the way > forward, but would require to implement own > layer to switch right NetCon base according > to socket AF domain, and type. So it would not be > easy task and solution based on actual FD to LwIP FD > translation could be used until then. > > Generally I am curious what works and where > are problems. I do not expect to have time or > find students this summer but I try to offer > project as theses and next summer and there > chance (small) that I find some studnet > to participate. > I am currently actively working on the lwip port to get it working with at least a few boards, along with a streamlined build system. I could only get the BBB running with a telnetd application that I added in the test/ directory in the rtems-lwip repository. I used the drivers from TI for BBB. > This summer is my main interrest with studnets > work focused on pysimCoder to boost usability. > > https://github.com/robertobucher/pysimCoder > > It is usable with preemptive GNU/Linux > on more targets, NuttX and adding support > for RTEMS would be easy as well. > Some demo with NuttX > > https://youtu.be/6HlGk3ecPNQ > > Same targets are supported by our support > for Matlab/Simulink, RTEMS is on my list > for this projet for many years as well, > so if somebody have interrest, I would help > by advice or some prototype (which I have > for RTEMS in some hacked state in the past) > > https://github.com/aa4cc/ert_linux/ > > Best wishes, > > Pavel > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On Sun, Jul 11, 2021 at 6:42 PM Chris Johns wrote: > > On 10/7/21 1:28 pm, Vijay Kumar Banerjee wrote: > > On Fri, Jul 9, 2021 at 8:25 PM Chris Johns wrote: > >> > >> On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > >>> I'm planning to do a throughput analysis on the RTEMS network stacks > >>> and I'm looking for some suggestions on the tools/applications for > >>> that if anyone has done something like that before. > >> > >> This is a great project. > >> > >>> If such application has not been used with RTEMS, then I might be > >>> willing to port it to RTEMS or write one from scratch as a net-demo > >>> maybe. Any resource/advice for that is welcome and much appreciated. > >> > >> Throughput is one parameter when dealing with networking and it is > >> important in > >> some applications while latency is another parameter that can be critical. > >> Consider a voice switch with operators using Push To Talk (PTT) buttons to > >> activate a radio's transmitter, an enable packet needs to be delivered > >> within > >> 10msec max in all cases. > >> > > This is an interesting point. Thanks for mentioning latency. > > In RTEMS and in an RTOS in general I also consider the latency for separate > socket paths to separate readers and/or concurrent readers and writers as > something important. A lot of stacks maintain a single giant lock for the > stack > and that serialises the processing through the stack. Libbsd does not have > this > limitation with it's fine grain locking. A protocol such as PTP benefits from > deterministic handling of packets. > Interesting. I'm making notes, I'll look at latency from different protocols. > >> I would look at removing the networking fabric from the analysis because > >> it is > >> subjective and can be effected by the NIC hardware, PHY configuration plus > >> any > >> externally connected equipment. > >> > > I'm approaching this by running different network stacks over the same > > hardware. I have a uC5282 that runs legacy networking and I have > > ported the driver to libbsd nexus device (dhcp doesn't work yet) and > > I'm able to see some difference in the round trip time over loopback > > with different stacks. > > Will your analysis look at architectures that support SMP and have various > cache > configurations? On a Zynq libbsd creates over 4000 locks and so there may be a > performance hit on smaller single core systems compared with multi-core > architectures that can run concurrent threads in the stack at the same time. > Yes, we plan to look at multicore architecture as well. Getting the target to support all three stacks would be the real challenge. > I think the 5282 may bias the results in a particular way and other archs will > bias in a different way. I do not see this as wrong or a problem, rather it is > something that needs to be accounted for so readers of the analysis do not get > the wrong impression. > We intend to analyze boards over multiple arch. > >> In terms of network stack performance for RTEMS you need to consider the > >> protocol, buffering used, size of the buffer pool, transmit and receive > >> paths, > >> they will have different characteristics, and target's memory effects such > >> as > >> caches. On top of this is filtering, ie packet filtering, and the types of > >> access. > >> > > Thanks for these interesting attributes to consider. I have done > > preliminary analysis over ICMP with packets of same size over > > different network stacks on the same board. > > > >> With libbsd there are a number of sysctl settings that effect the > >> performance. > >> How will you manage these? > >> > > I'm not sure. I didn't know about the possible performance difference > > based on sysctl settings. This would be relevant for any user and I > > would like to explore it. Could you please point to some resources or > > examples? > > There are a lot of posts on the net on this topic (search: "freebsd tune > network > sysctl") and the values can be technical but they do make a difference for > different data workflows. There is no single set of values what work > universally > and for libbsd this is OK because I encourage users to explore the settings > and > see what works for them. There can be a memory used vs performance trade off. > We > support the sysctl API and there is a sysctl command for the shell. > I found some nice articles, thanks. I'll explore it further. Thank you for the great points, it helped me get a better idea of what I should be looking at. Best regards, Vijay > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On Fri, Jul 9, 2021 at 8:25 PM Chris Johns wrote: > > On 2/7/21 4:40 am, Vijay Kumar Banerjee wrote: > > I'm planning to do a throughput analysis on the RTEMS network stacks > > and I'm looking for some suggestions on the tools/applications for > > that if anyone has done something like that before. > > This is a great project. > > > If such application has not been used with RTEMS, then I might be > > willing to port it to RTEMS or write one from scratch as a net-demo > > maybe. Any resource/advice for that is welcome and much appreciated. > > Throughput is one parameter when dealing with networking and it is important > in > some applications while latency is another parameter that can be critical. > Consider a voice switch with operators using Push To Talk (PTT) buttons to > activate a radio's transmitter, an enable packet needs to be delivered within > 10msec max in all cases. > This is an interesting point. Thanks for mentioning latency. > I would look at removing the networking fabric from the analysis because it is > subjective and can be effected by the NIC hardware, PHY configuration plus any > externally connected equipment. > I'm approaching this by running different network stacks over the same hardware. I have a uC5282 that runs legacy networking and I have ported the driver to libbsd nexus device (dhcp doesn't work yet) and I'm able to see some difference in the round trip time over loopback with different stacks. > In terms of network stack performance for RTEMS you need to consider the > protocol, buffering used, size of the buffer pool, transmit and receive paths, > they will have different characteristics, and target's memory effects such as > caches. On top of this is filtering, ie packet filtering, and the types of > access. > Thanks for these interesting attributes to consider. I have done preliminary analysis over ICMP with packets of same size over different network stacks on the same board. > With libbsd there are a number of sysctl settings that effect the performance. > How will you manage these? > I'm not sure. I didn't know about the possible performance difference based on sysctl settings. This would be relevant for any user and I would like to explore it. Could you please point to some resources or examples? > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: DTB for BBB?
On Wed, Jul 7, 2021 at 1:27 PM Shiro wrote: > > > > > >> Question regarding the correct DTS for BBB: in section 8.2.3.2 of the > >> online docs: > >> https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html?highlight=dts#beagle > >> > >> I don't follow this: > >> > >> We build the dtb from the FreeBSD source matching the commit hash from the > >> libbsd HEAD of freebsd-org. For example if the HEAD is at > >> “19a6ceb89dbacf74697d493e48c388767126d418” … > >> > > The HEAD is determined by the HEAD of the freebsd-org submodule in the > > rtems-libbsd repository, which is basically the FreeBSD source. Though > > the documentation says that we should always take commit hash matching > > with the submodule HEAD, the commit id that you found in the > > documentation (i.e 19a6ceb) is the last one that has been thoroughly > > tested. You might want to use that id and build the dtb. > > > > To build the DTB, you can use the script provided by FreeBSD in the > > following source directory: > > sys/tools/fdt/make_dtb.sh > > > > And the right dts to build is sys/gnu/dts/arm/am335x-boneblack.dts > No problem! Glad it helped. Maybe we need to make it clear in the documentation as well. :) > > Thank you for the detailed explanation. Now I get it! ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
libbsd: Network interface is not configured
Hi all, I'm working on adding a nexus device driver for uC5282, and I got as far as getting the telnetd started on port 23, and I can ping the loopback interface. However, the test apps were crashing before I made some environment variable changes, so I'm assuming that the "Network interface is not configured" might be a configuration issue as well. The error I'm getting: err: fec0: ipv4_sendrawpacket: Network interface is not configured ifconfig: SHLL [/] # ifconfig fec0: flags=8843 metric 0 mtu 1500 ether 00:06:3b:02:cd:1b inet6 fe80::206:3bff:fe02:cd1b%fec0 prefixlen 64 tentative scopeid 0x1 nd6 options=21 lo0: flags=8049 metric 0 mtu 16384 options=680003 inet 127.0.0.1 netmask 0xff00 inet6 ::1 prefixlen 128 inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2 nd6 options=21 groups: lo relevant environment variables: HWADDR0=00:06:3B:02:CD:1B FW_VERSION=010810003 _0=1000:40:RW RAMIMAGE=yes CACHE=on NETMAST=255.255.255.0 NETMASK=255.255.255.0 IP_GATEWAY=255.255.255.0 TFTPSERVER=192.168.100.1 TFTPIMAGE=image.cramfs HOSTNAME=coldfire SERVER=10.0.0.161 NAMESERVER=10.0.0.167 IPADDR0=10.0.0.27 IPADDR0_100FULL=y Any suggestion or help in getting it running is much appreciated. Also, I do not have a JTAG emulator supported for MCF5282, so it's a bit difficult to debug on the board. Any advice on debugging will also be very helpful. Best regards, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: DTB for BBB?
Hi David, On Tue, Jul 6, 2021 at 1:34 PM Shiro wrote: > > Hello, > > I’m new to RTEMS (but not new to embedded RTOS deployment). I worked through > the BBB QuickStart and have run hello.exe on a BBB. > Welcome to RTEMS! > Question regarding the correct DTS for BBB: in section 8.2.3.2 of the online > docs: > https://docs.rtems.org/branches/master/user/bsps/bsps-arm.html?highlight=dts#beagle > > I don't follow this: > > We build the dtb from the FreeBSD source matching the commit hash from the > libbsd HEAD of freebsd-org. For example if the HEAD is at > “19a6ceb89dbacf74697d493e48c388767126d418” … > The HEAD is determined by the HEAD of the freebsd-org submodule in the rtems-libbsd repository, which is basically the FreeBSD source. Though the documentation says that we should always take commit hash matching with the submodule HEAD, the commit id that you found in the documentation (i.e 19a6ceb) is the last one that has been thoroughly tested. You might want to use that id and build the dtb. To build the DTB, you can use the script provided by FreeBSD in the following source directory: sys/tools/fdt/make_dtb.sh And the right dts to build is sys/gnu/dts/arm/am335x-boneblack.dts > > Can anyone point me to where HEAD is determined? And how it matched into the > FreeBSD.org tree? > Hope this helps. Best regards, Vijay > > Best regards, > -david > > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS on uC5282
On Tue, Jul 6, 2021 at 9:58 AM Johnson, Andrew N. wrote: > > Hi Vijay, > > On Jul 4, 2021, at 6:08 PM, Vijay Kumar Banerjee wrote: > > I have a uC5282 board running uClinux and I was wondering if someone > has instructions for converting the RTEMS exe files into boot files > that can be booted from the ram buffer (using `goram` from > uCbootloader. > > The RTEMS documentation is empty: > https://docs.rtems.org/branches/master/user/bsps/bsps-m68k.html#uc5282 > > I will populate this section in the documentation once I figure out > how to run and debug RTEMS executables on it. Any help is much > appreciated. > > > It’s likely that most if not all uC5282 devices running RTEMS to date have > been EPICS IOCs. We finally released EPICS 7.0.6 over the weekend which > contains (initial & experimental) support for RTEMS 5, but while I have > compiled code for our RTEMS-uC5282 target I haven’t actually run it on a real > device. In any case the command that we have always used to build bootable > EPICS IOCs with on that target is this line from our GNUmake-based build > system: > > $(RTEMS_TOOLS)/bin/$(OBJCOPY_FOR_TARGET) -O binary -R .comment -S $< $@ > > This worked. Thanks! > where $@ is the bootable file and $< the file output by the link-line: > > An explicit example output from a build that I just ran: > > /usr/local/vw/rtems/rtems-5.1/bin/m68k-rtems5-g++ > -B/usr/local/vw/rtems/rtems-5.1/m68k-rtems5/uC5282/lib/ -specs bsp_specs > -qrtems -o libComTestHarness -static > -L/home/phoebus4/ANJ/epics/base/7.0/lib/RTEMS-uC5282 -mcpu=5282 -u > POSIX_Init epicsTypesTest.o epicsInlineTest1.o epicsInlineTest2.o > > ... snipped ... epicsTimeZoneTest.o rtemsTestHarness.o rtemsTestData.o > -lCom -lm -lrtemsCom -lCom -ltftpfs -lnfs -lz -ltelnetd -lrtemscpu -lc > -lm -lgcc > /usr/local/vw/rtems/rtems-5.1/bin/m68k-rtems5-objcopy -O binary -R .comment > -S libComTestHarness libComTestHarness.boot > Installing created executable ../../../../bin/RTEMS-uC5282/libComTestHarness > Installing created executable > ../../../../bin/RTEMS-uC5282/libComTestHarness.boot > > > We then load the libComTestHarness.boot file into the device using tftp. > I tried the XMODEM file transfer, which seems very slow at 9600, I'll give it a shot with tftp as well. Thank you for mentioning. > For EPICS applications the BSP may have to be built with the legacy network > stack, but if so that’s due to our initialization code which probably hasn’t > been updated yet. > I have it built with the legacy network stack. Thank you for the commands, I will update the RTEMS side of documentation soon. Best regards, Vijay > HTH, > > - Andrew > > -- > Complexity comes for free, simplicity you have to work for. > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: RTEMS on uC5282
On Sun, Jul 4, 2021 at 5:08 PM Vijay Kumar Banerjee wrote: > > Hi, > > I have a uC5282 board running uClinux and I was wondering if someone > has instructions for converting the RTEMS exe files into boot files > that can be booted from the ram buffer (using `goram` from > uCbootloader. > This command works great! m68k-rtems6-objcopy -O binary capture.exe capture.ralf I will soon write a documentation for uC5282 (before I forget how I did it :p ) > The RTEMS documentation is empty: > https://docs.rtems.org/branches/master/user/bsps/bsps-m68k.html#uc5282 > > I will populate this section in the documentation once I figure out > how to run and debug RTEMS executables on it. Any help is much > appreciated. > > > > Best regards, > Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RTEMS on uC5282
Hi, I have a uC5282 board running uClinux and I was wondering if someone has instructions for converting the RTEMS exe files into boot files that can be booted from the ram buffer (using `goram` from uCbootloader. The RTEMS documentation is empty: https://docs.rtems.org/branches/master/user/bsps/bsps-m68k.html#uc5282 I will populate this section in the documentation once I figure out how to run and debug RTEMS executables on it. Any help is much appreciated. Best regards, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On Fri, Jul 2, 2021 at 10:51 AM Christian Mauderer wrote: > > Hello Vijay, > > On 01/07/2021 22:16, Vijay Kumar Banerjee wrote: > > Hi Kinsey, > > > > On Thu, Jul 1, 2021 at 12:57 PM Kinsey Moore > > wrote: > >> > >> On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: > >>> Hi all, > >>> > >>> I'm planning to do a throughput analysis on the RTEMS network stacks > >>> and I'm looking for some suggestions on the tools/applications for > >>> that if anyone has done something like that before. > >> > >> Stephen Clark has recently added TTCP tests/commands to LibBSD which I > >> think would be a great starting point. > >> > > Thanks for the point! It looks interesting and I'll try it out. > > If GPL is no problem (which shouldn't be the case for a specific > throughput test application) you could also take a look at nuttcp. > That's basically a fork of a fork of ttcp. It might has some new > features that are not there in the original and quite old ttcp. > Thanks Christian, I tried ttcp and nuttcp on Linux and this looks great. GPL is certainly not a problem in our use case, so nuttcp is a good idea as well. > Beneath the ttcp family, there is also iperf (2 or 3) which has a BSD > license. Note that despite iperf2 and iperf3 are named similar, they are > both different projects and both are actively maintained. > Thanks. I haven't checked iperf2/3 yet, but I will certainly give it a shot. Best regards, Vijay > Best regards > > Christian > > > > > > > Best regards, > > Vijay > >> > >> Kinsey > >> > >> ___ > >> devel mailing list > >> devel@rtems.org > >> http://lists.rtems.org/mailman/listinfo/devel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel > > ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
On Thu, Jul 1, 2021 at 3:44 PM Joel Sherrill wrote: > > Have you seen this on benchmarking? > https://datatracker.ietf.org/doc/html/rfc8238 > Thank you for this link. This is insightful and gives a clear idea for the benchmarking work. > On Thu, Jul 1, 2021 at 3:16 PM Vijay Kumar Banerjee wrote: > > > > Hi Kinsey, > > > > On Thu, Jul 1, 2021 at 12:57 PM Kinsey Moore > > wrote: > > > > > > On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: > > > > Hi all, > > > > > > > > I'm planning to do a throughput analysis on the RTEMS network stacks > > > > and I'm looking for some suggestions on the tools/applications for > > > > that if anyone has done something like that before. > > > > > > Stephen Clark has recently added TTCP tests/commands to LibBSD which I > > > think would be a great starting point. > > > > > Thanks for the point! It looks interesting and I'll try it out. > > > > > > Best regards, > > Vijay > > > > > > Kinsey > > > > > > ___ > > > devel mailing list > > > devel@rtems.org > > > http://lists.rtems.org/mailman/listinfo/devel > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Throughput/Goodput analysis on RTEMS
Hi Kinsey, On Thu, Jul 1, 2021 at 12:57 PM Kinsey Moore wrote: > > On 7/1/2021 13:40, Vijay Kumar Banerjee wrote: > > Hi all, > > > > I'm planning to do a throughput analysis on the RTEMS network stacks > > and I'm looking for some suggestions on the tools/applications for > > that if anyone has done something like that before. > > Stephen Clark has recently added TTCP tests/commands to LibBSD which I > think would be a great starting point. > Thanks for the point! It looks interesting and I'll try it out. Best regards, Vijay > > Kinsey > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Throughput/Goodput analysis on RTEMS
Hi all, I'm planning to do a throughput analysis on the RTEMS network stacks and I'm looking for some suggestions on the tools/applications for that if anyone has done something like that before. If such application has not been used with RTEMS, then I might be willing to port it to RTEMS or write one from scratch as a net-demo maybe. Any resource/advice for that is welcome and much appreciated. Thank you, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] bsps/powerpc, bsps/shared: Move remaining legacy networking header files
On Wed, Jun 23, 2021 at 3:26 PM Joel Sherrill wrote: > > > > On Wed, Jun 23, 2021, 2:31 PM Vijay Kumar Banerjee wrote: >> >> On Wed, Jun 23, 2021 at 1:24 PM Joel Sherrill wrote: >> > >> > Assuming you built the bsps in question, I'm ok with this. >> > >> I tested the build and install for both the bsps involved. > > > Then I'm cool with pushing it. >> Pushed this along with the corresponding legacy stack commit. >> >> > Any insight info the tftp code? Did it really need rtems_bsdnet.h? >> > >> It looks like, the tftp code uses the hostname and >> rtems_bsdnet_bootp_server_address from the legacy stack. The >> rtems_bsdnet.h has the extern declaration for it. I couldn't come up >> with a clean solution to add the values to tftp code. Any suggestion? >> Or we can make copies of this in each stack. > > > Is there an equivalent method in the new stack? This may be a case for some > level of compatibility between them for RTEMS specifics. > >> >> I'm planning to work on two different networking submodule >> "net-services" and "net-drivers" for the common services and to expand >> the driver support for each stack. This can shift to the services repo >> later if we make copies of it as a temporary workaround. > > > Also the old network demos are stack independent past initialization. They > just need a bsp/lab specific configuration to be useful. The default > configuration is loopback which isn't useful for testing or showing basic use > of features. > > This part should be a separate thread. :) > Started the work on the submodule. That's in a different thread already. :D Thanks, Vijay >> >> > On Wed, Jun 23, 2021, 2:21 PM Vijay Kumar Banerjee wrote: >> >> >> >> --- >> >> bsps/headers.am |3 - >> >> bsps/include/grlib/greth.h| 165 -- >> >> bsps/include/grlib/network_interface_add.h| 47 - >> >> bsps/powerpc/beatnik/headers.am |3 - >> >> bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 - >> >> bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 - >> >> bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 - >> >> bsps/shared/grlib/net/greth.c | 1663 - >> >> spec/build/bsps/objgrlib.yml |2 - >> >> .../build/bsps/powerpc/beatnik/bspbeatnik.yml |3 - >> >> 10 files changed, 2364 deletions(-) >> >> delete mode 100644 bsps/include/grlib/greth.h >> >> delete mode 100644 bsps/include/grlib/network_interface_add.h >> >> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h >> >> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h >> >> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h >> >> delete mode 100644 bsps/shared/grlib/net/greth.c >> >> >> >> diff --git a/bsps/headers.am b/bsps/headers.am >> >> index b89e5c2b28..b5821564b1 100644 >> >> --- a/bsps/headers.am >> >> +++ b/bsps/headers.am >> >> @@ -82,7 +82,6 @@ include_grlib_HEADERS += >> >> ../../bsps/include/grlib/gradcdac.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/grascs.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/grcan.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/grctm.h >> >> -include_grlib_HEADERS += ../../bsps/include/grlib/greth.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/grgpio.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/griommu.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/grlib.h >> >> @@ -102,7 +101,6 @@ include_grlib_HEADERS += >> >> ../../bsps/include/grlib/l2c.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/l4stat.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/mctrl.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/memscrub.h >> >> -include_grlib_HEADERS += ../../bsps/include/grlib/network_interface_add.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/occan.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/pcif.h >> >> include_grlib_HEADERS += ../../bsps/include/grlib/satcan.h >> >> @@ -118,7 +116,6 @@ include_libchip_HEADERS += >> >> ../../bsps/include/libchip/ata.h >> >> include_libchip_HEADERS += ../../bsps/include/libchip/ata_internal.h >&g
Re: rtems-net-services submodule for networking stacks
On Thu, Jun 24, 2021 at 5:17 PM Joel Sherrill wrote: > > > > On Thu, Jun 24, 2021, 5:43 PM Vijay Kumar Banerjee wrote: >> >> Hi all, >> >> I want to move the common network services like telnetd, tftp, to a >> separate submodule rtems-net-services. This submodule will be added to >> the networking stacks, and built using their respective waf modules. >> >> The plan is to define macros from the legacy stack waf system, so that >> the net-services code (like tftp) can make use of the macros without >> hard coding any values (like the priority in telnetd). >> >> I would appreciate any thoughts or suggestions in this direction. > > > I think this is a great idea and the only way to avoid duplication. I would > like to see it have services and what are now on network-demos. > > The complexity is that the network demos are user facing samples and > examples. Even though they can be compiled with the default loopback > interface, they aren't interesting that way. They need a bsp/lab/stack > specific configuration and initialization. > > The network configuration for them needs to be set up such that either stack > can be initialised and configured. This probably just means a method called > from the independent code and a netconfig.c file which can be specified at > configure time > Thanks. I propose to add a default config file, which can be overwritten when there's manual input by the user. We have taken the same approach in rtems-littlevgl for the graphics configurations. Initially, the services repo will have just telnet, and tftp and we'll expand on top of it, taking feedback from devel as we progress. > Bonus points if the sample shows a network usage that is applicable in a host > environment, the application starts at main() and can be built native or for > RTEMS. > > --joel > >> >> >> Best regards, >> Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
rtems-net-services submodule for networking stacks
Hi all, I want to move the common network services like telnetd, tftp, to a separate submodule rtems-net-services. This submodule will be added to the networking stacks, and built using their respective waf modules. The plan is to define macros from the legacy stack waf system, so that the net-services code (like tftp) can make use of the macros without hard coding any values (like the priority in telnetd). I would appreciate any thoughts or suggestions in this direction. Best regards, Vijay ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] bsps/powerpc, bsps/shared: Move remaining legacy networking header files
On Wed, Jun 23, 2021 at 1:24 PM Joel Sherrill wrote:
>
> Assuming you built the bsps in question, I'm ok with this.
>
I tested the build and install for both the bsps involved.
> Any insight info the tftp code? Did it really need rtems_bsdnet.h?
>
It looks like, the tftp code uses the hostname and
rtems_bsdnet_bootp_server_address from the legacy stack. The
rtems_bsdnet.h has the extern declaration for it. I couldn't come up
with a clean solution to add the values to tftp code. Any suggestion?
Or we can make copies of this in each stack.
I'm planning to work on two different networking submodule
"net-services" and "net-drivers" for the common services and to expand
the driver support for each stack. This can shift to the services repo
later if we make copies of it as a temporary workaround.
> On Wed, Jun 23, 2021, 2:21 PM Vijay Kumar Banerjee wrote:
>>
>> ---
>> bsps/headers.am |3 -
>> bsps/include/grlib/greth.h| 165 --
>> bsps/include/grlib/network_interface_add.h| 47 -
>> bsps/powerpc/beatnik/headers.am |3 -
>> bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 -
>> bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 -
>> bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 -
>> bsps/shared/grlib/net/greth.c | 1663 -
>> spec/build/bsps/objgrlib.yml |2 -
>> .../build/bsps/powerpc/beatnik/bspbeatnik.yml |3 -
>> 10 files changed, 2364 deletions(-)
>> delete mode 100644 bsps/include/grlib/greth.h
>> delete mode 100644 bsps/include/grlib/network_interface_add.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
>> delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
>> delete mode 100644 bsps/shared/grlib/net/greth.c
>>
>> diff --git a/bsps/headers.am b/bsps/headers.am
>> index b89e5c2b28..b5821564b1 100644
>> --- a/bsps/headers.am
>> +++ b/bsps/headers.am
>> @@ -82,7 +82,6 @@ include_grlib_HEADERS +=
>> ../../bsps/include/grlib/gradcdac.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grascs.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grcan.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grctm.h
>> -include_grlib_HEADERS += ../../bsps/include/grlib/greth.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grgpio.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/griommu.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/grlib.h
>> @@ -102,7 +101,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/l2c.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/l4stat.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/mctrl.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/memscrub.h
>> -include_grlib_HEADERS += ../../bsps/include/grlib/network_interface_add.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/occan.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/pcif.h
>> include_grlib_HEADERS += ../../bsps/include/grlib/satcan.h
>> @@ -118,7 +116,6 @@ include_libchip_HEADERS +=
>> ../../bsps/include/libchip/ata.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/ata_internal.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/disp_hcms29xx.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/ds1375-rtc.h
>> -include_libchip_HEADERS += ../../bsps/include/libchip/greth.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-2b-eeprom.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-ds1621.h
>> include_libchip_HEADERS += ../../bsps/include/libchip/i2c-sc620.h
>> diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
>> deleted file mode 100644
>> index e7970a79f7..00
>> --- a/bsps/include/grlib/greth.h
>> +++ /dev/null
>> @@ -1,165 +0,0 @@
>> -/*
>> - * Cobham Gaisler ethernet MAC driver
>> - * adapted from Opencores driver by Marko Isomaki
>> - *
>> - * The license and distribution terms for this file may be
>> - * found in found in the file LICENSE in this distribution or at
>> - * http://www.rtems.org/license/LICENSE.
>> - */
>> -
>> -#ifndef __GRETH_H__
>> -#define __GRETH_H__
>> -
>> -#ifdef __cplusplus
>> -extern "C" {
>> -#endif
>> -
>> -/* Ethernet configuration registers */
>> -
>> -typedef struct _greth_regs {
>> - volatile uint32_t ctrl; /* Ctrl Register */
>> - volatile uint32_t status; /* Sta
[PATCH rtems-net-legacy] bsps: Add remaining networking header files from RTEMS repository
---
bsp_drivers.py| 1 +
bsps/include/grlib/greth.h| 165 +++
bsps/include/grlib/network_interface_add.h| 47 ++
bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 +
bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 ++
bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 ++
6 files changed, 691 insertions(+)
create mode 100644 bsps/include/grlib/greth.h
create mode 100644 bsps/include/grlib/network_interface_add.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
create mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
diff --git a/bsp_drivers.py b/bsp_drivers.py
index bb31789..7d07d3d 100644
--- a/bsp_drivers.py
+++ b/bsp_drivers.py
@@ -72,4 +72,5 @@ def bsp_files(bld):
if bsp in special_case_sources:
source_files[bsp].extend(special_case_sources[bsp])
include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'net'))
+include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'include'))
return (include_dirs, source_files)
diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
new file mode 100644
index 000..e7970a7
--- /dev/null
+++ b/bsps/include/grlib/greth.h
@@ -0,0 +1,165 @@
+/*
+ * Cobham Gaisler ethernet MAC driver
+ * adapted from Opencores driver by Marko Isomaki
+ *
+ * The license and distribution terms for this file may be
+ * found in found in the file LICENSE in this distribution or at
+ * http://www.rtems.org/license/LICENSE.
+ */
+
+#ifndef __GRETH_H__
+#define __GRETH_H__
+
+#ifdef __cplusplus
+extern "C" {
+#endif
+
+/* Ethernet configuration registers */
+
+typedef struct _greth_regs {
+ volatile uint32_t ctrl; /* Ctrl Register */
+ volatile uint32_t status; /* Status Register */
+ volatile uint32_t mac_addr_msb; /* Bit 47-32 of MAC address */
+ volatile uint32_t mac_addr_lsb; /* Bit 31-0 of MAC address */
+ volatile uint32_t mdio_ctrl;/* MDIO control and status */
+ volatile uint32_t txdesc; /* Transmit descriptor pointer */
+ volatile uint32_t rxdesc; /* Receive descriptor pointer */
+ volatile uint32_t edcl; /* EDCL IP register */
+ volatile uint32_t ht_msb; /* Multicast MSB hash */
+ volatile uint32_t ht_lsb; /* Multicast LSB hash */
+} greth_regs;
+
+#define GRETH_TOTAL_BD 128
+#define GRETH_MAXBUF_LEN 1520
+
+/* Tx BD */
+#define GRETH_TXD_ENABLE 0x0800 /* Tx BD Enable */
+#define GRETH_TXD_WRAP0x1000 /* Tx BD Wrap (last BD) */
+#define GRETH_TXD_IRQ 0x2000 /* Tx BD IRQ Enable */
+#define GRETH_TXD_MORE0x2 /* Tx BD More (more descs for packet) */
+#define GRETH_TXD_IPCS0x4 /* Tx BD insert ip chksum */
+#define GRETH_TXD_TCPCS 0x8 /* Tx BD insert tcp chksum */
+#define GRETH_TXD_UDPCS 0x10 /* Tx BD insert udp chksum */
+
+#define GRETH_TXD_UNDERRUN0x4000 /* Tx BD Underrun Status */
+#define GRETH_TXD_RETLIM 0x8000 /* Tx BD Retransmission Limit Status */
+#define GRETH_TXD_LATECOL 0x1 /* Tx BD Late Collision */
+
+#define GRETH_TXD_STATS (GRETH_TXD_UNDERRUN| \
+ GRETH_TXD_RETLIM | \
+ GRETH_TXD_LATECOL)
+
+#define GRETH_TXD_CS (GRETH_TXD_IPCS| \
+ GRETH_TXD_TCPCS | \
+ GRETH_TXD_UDPCS)
+
+/* Rx BD */
+#define GRETH_RXD_ENABLE 0x0800 /* Rx BD Enable */
+#define GRETH_RXD_WRAP0x1000 /* Rx BD Wrap (last BD) */
+#define GRETH_RXD_IRQ 0x2000 /* Rx BD IRQ Enable */
+
+#define GRETH_RXD_DRIBBLE 0x4000 /* Rx BD Dribble Nibble Status */
+#define GRETH_RXD_TOOLONG 0x8000 /* Rx BD Too Long Status */
+#define GRETH_RXD_CRCERR 0x1 /* Rx BD CRC Error Status */
+#define GRETH_RXD_OVERRUN 0x2 /* Rx BD Overrun Status */
+#define GRETH_RXD_LENERR 0x4 /* Rx BD Length Error */
+#define GRETH_RXD_ID 0x4 /* Rx BD IP Detected */
+#define GRETH_RXD_IR 0x4 /* Rx BD IP Chksum Error */
+#define GRETH_RXD_UD 0x4 /* Rx BD UDP Detected*/
+#define GRETH_RXD_UR 0x4 /* Rx BD UDP Chksum Error */
+#define GRETH_RXD_TD 0x4 /* Rx BD TCP Detected */
+#define GRETH_RXD_TR 0x4 /* Rx BD TCP Chksum Error */
+
+
+#define GRETH_RXD_STATS (GRETH_RXD_OVERRUN | \
+ GRETH_RXD_DRIBBLE | \
+ GRETH_RXD_TOOLONG | \
+ GRETH_RXD_CRCERR)
+
+/* CTRL Register */
+#define GRETH_CTRL_TXEN 0x0001 /* Transmit Enable */
+#define GRETH_CTRL_RXEN
[PATCH rtems] bsps/powerpc, bsps/shared: Move remaining legacy networking header files
---
bsps/headers.am |3 -
bsps/include/grlib/greth.h| 165 --
bsps/include/grlib/network_interface_add.h| 47 -
bsps/powerpc/beatnik/headers.am |3 -
bsps/powerpc/beatnik/include/bsp/if_em_pub.h | 22 -
bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h | 30 -
bsps/powerpc/beatnik/include/bsp/if_mve_pub.h | 426 -
bsps/shared/grlib/net/greth.c | 1663 -
spec/build/bsps/objgrlib.yml |2 -
.../build/bsps/powerpc/beatnik/bspbeatnik.yml |3 -
10 files changed, 2364 deletions(-)
delete mode 100644 bsps/include/grlib/greth.h
delete mode 100644 bsps/include/grlib/network_interface_add.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_em_pub.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_gfe_pub.h
delete mode 100644 bsps/powerpc/beatnik/include/bsp/if_mve_pub.h
delete mode 100644 bsps/shared/grlib/net/greth.c
diff --git a/bsps/headers.am b/bsps/headers.am
index b89e5c2b28..b5821564b1 100644
--- a/bsps/headers.am
+++ b/bsps/headers.am
@@ -82,7 +82,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/gradcdac.h
include_grlib_HEADERS += ../../bsps/include/grlib/grascs.h
include_grlib_HEADERS += ../../bsps/include/grlib/grcan.h
include_grlib_HEADERS += ../../bsps/include/grlib/grctm.h
-include_grlib_HEADERS += ../../bsps/include/grlib/greth.h
include_grlib_HEADERS += ../../bsps/include/grlib/grgpio.h
include_grlib_HEADERS += ../../bsps/include/grlib/griommu.h
include_grlib_HEADERS += ../../bsps/include/grlib/grlib.h
@@ -102,7 +101,6 @@ include_grlib_HEADERS += ../../bsps/include/grlib/l2c.h
include_grlib_HEADERS += ../../bsps/include/grlib/l4stat.h
include_grlib_HEADERS += ../../bsps/include/grlib/mctrl.h
include_grlib_HEADERS += ../../bsps/include/grlib/memscrub.h
-include_grlib_HEADERS += ../../bsps/include/grlib/network_interface_add.h
include_grlib_HEADERS += ../../bsps/include/grlib/occan.h
include_grlib_HEADERS += ../../bsps/include/grlib/pcif.h
include_grlib_HEADERS += ../../bsps/include/grlib/satcan.h
@@ -118,7 +116,6 @@ include_libchip_HEADERS += ../../bsps/include/libchip/ata.h
include_libchip_HEADERS += ../../bsps/include/libchip/ata_internal.h
include_libchip_HEADERS += ../../bsps/include/libchip/disp_hcms29xx.h
include_libchip_HEADERS += ../../bsps/include/libchip/ds1375-rtc.h
-include_libchip_HEADERS += ../../bsps/include/libchip/greth.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-2b-eeprom.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-ds1621.h
include_libchip_HEADERS += ../../bsps/include/libchip/i2c-sc620.h
diff --git a/bsps/include/grlib/greth.h b/bsps/include/grlib/greth.h
deleted file mode 100644
index e7970a79f7..00
--- a/bsps/include/grlib/greth.h
+++ /dev/null
@@ -1,165 +0,0 @@
-/*
- * Cobham Gaisler ethernet MAC driver
- * adapted from Opencores driver by Marko Isomaki
- *
- * The license and distribution terms for this file may be
- * found in found in the file LICENSE in this distribution or at
- * http://www.rtems.org/license/LICENSE.
- */
-
-#ifndef __GRETH_H__
-#define __GRETH_H__
-
-#ifdef __cplusplus
-extern "C" {
-#endif
-
-/* Ethernet configuration registers */
-
-typedef struct _greth_regs {
- volatile uint32_t ctrl; /* Ctrl Register */
- volatile uint32_t status; /* Status Register */
- volatile uint32_t mac_addr_msb; /* Bit 47-32 of MAC address */
- volatile uint32_t mac_addr_lsb; /* Bit 31-0 of MAC address */
- volatile uint32_t mdio_ctrl;/* MDIO control and status */
- volatile uint32_t txdesc; /* Transmit descriptor pointer */
- volatile uint32_t rxdesc; /* Receive descriptor pointer */
- volatile uint32_t edcl; /* EDCL IP register */
- volatile uint32_t ht_msb; /* Multicast MSB hash */
- volatile uint32_t ht_lsb; /* Multicast LSB hash */
-} greth_regs;
-
-#define GRETH_TOTAL_BD 128
-#define GRETH_MAXBUF_LEN 1520
-
-/* Tx BD */
-#define GRETH_TXD_ENABLE 0x0800 /* Tx BD Enable */
-#define GRETH_TXD_WRAP0x1000 /* Tx BD Wrap (last BD) */
-#define GRETH_TXD_IRQ 0x2000 /* Tx BD IRQ Enable */
-#define GRETH_TXD_MORE0x2 /* Tx BD More (more descs for packet) */
-#define GRETH_TXD_IPCS0x4 /* Tx BD insert ip chksum */
-#define GRETH_TXD_TCPCS 0x8 /* Tx BD insert tcp chksum */
-#define GRETH_TXD_UDPCS 0x10 /* Tx BD insert udp chksum */
-
-#define GRETH_TXD_UNDERRUN0x4000 /* Tx BD Underrun Status */
-#define GRETH_TXD_RETLIM 0x8000 /* Tx BD Retransmission Limit Status */
-#define GRETH_TXD_LATECOL 0x1 /* Tx BD Late Collision */
-
-#define GRETH_TXD_STATS (GRETH_TXD_UNDERRUN| \
- GRETH_TXD_RETLIM | \
- GRETH_TXD_LATECOL)
-
-#define GRETH_TXD_CS
Re: [PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level
On Wed, Jun 2, 2021 at 9:21 AM Gedare Bloom wrote: > > looks ok > Thanks. Pushed! > On Sun, May 30, 2021 at 3:12 PM Vijay Kumar Banerjee wrote: > > > > --- > > eng/vc-authors.rst | 46 ++ > > 1 file changed, 46 insertions(+) > > > > diff --git a/eng/vc-authors.rst b/eng/vc-authors.rst > > index dcbbeb9..179ad08 100644 > > --- a/eng/vc-authors.rst > > +++ b/eng/vc-authors.rst > > @@ -166,6 +166,52 @@ flag to prevent merge from issuing an automatic merge > > commit message. > > When you have committed changes on a branch that is public/shared with > > another > > developer you should not rebase that branch. > > > > +Migrate a Personal Repository to top-level > > +-- > > + > > +Once a project is production ready in the personal repository, it's time to > > +migrate it to the top-level RTEMS git directory. First, the project > > directory > > +needs to be copied and then the permissions need to be set, so that > > everyone can > > +push into that repository. > > + > > +.. code-block:: shell > > + > > + cp -R /data/git/user/my-rtems-project.git /data/git > > + cd /data/git/my-rtems-project.git > > + chgrp -R gitrw ./ > > + chmod -R g+rws ./ > > + > > +Then copy the post-receive script from the rtems.git directory and change > > the > > +name of REPO. > > + > > +.. code-block:: shell > > + > > + cp /data/git/rtems.git/hooks/post-receive > > /data/git/my-rtems-project.git/hooks/ > > + > > +After making the change the post-receive script in the new repository > > should > > +look like this > > + > > +.. code-block:: shell > > + > > + #!/bin/sh > > + # > > + # The "post-receive" script is run after receive-pack has accepted a pack > > + # and the repository has been updated. It is passed arguments in through > > + # stdin in the form > > + # > > + # For example: > > + # aa453216d1b3e49e7f6f98441fa56946ddcd6a20 > > 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master > > + # > > + > > + REPO=my-rtems-project > > + > > + . /data/support/git-support/hooks/post-receive-0 > > + . /data/support/git-support/hooks/post-receive-1 > > + #. /data/support/git-support/hooks/post-receive-2 > > + . /data/support/git-support/hooks/post-receive-3 > > + . /data/support/git-support/hooks/post-receive-4 > > + . /data/support/git-support/hooks/post-receive-5 > > + > > GIT Push Configuration > > -- > > > > -- > > 2.26.2 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libdebugger: Fix for sockaddr_in not being initialized
On Tue, Jun 1, 2021 at 12:20 PM Joel Sherrill wrote:
>
> This looks like it should fix the issue.
>
> OK to push.
>
Pushed. Thanks.
> On Tue, Jun 1, 2021 at 1:06 PM Harrison Edward Gerber
> wrote:
>>
>> From: Harrison Edward Gerber
>>
>> See also CID 1468684
>>
>> Closes #4445
>> ---
>> cpukit/libdebugger/rtems-debugger-remote-tcp.c | 2 +-
>> 1 file changed, 1 insertion(+), 1 deletion(-)
>>
>> diff --git a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> index 696e2deb8c..440baa9b66 100644
>> --- a/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> +++ b/cpukit/libdebugger/rtems-debugger-remote-tcp.c
>> @@ -122,7 +122,7 @@ static int
>> tcp_remote_connect(rtems_debugger_remote* remote)
>> {
>>intld;
>> - struct sockaddr_in addr;
>> + struct sockaddr_in addr = {0};
>>socklen_t opt;
>>socklen_t len;
>>bool running;
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-docs] eng/vc-authors: Add section on migrating personal repo to top-level
--- eng/vc-authors.rst | 46 ++ 1 file changed, 46 insertions(+) diff --git a/eng/vc-authors.rst b/eng/vc-authors.rst index dcbbeb9..179ad08 100644 --- a/eng/vc-authors.rst +++ b/eng/vc-authors.rst @@ -166,6 +166,52 @@ flag to prevent merge from issuing an automatic merge commit message. When you have committed changes on a branch that is public/shared with another developer you should not rebase that branch. +Migrate a Personal Repository to top-level +-- + +Once a project is production ready in the personal repository, it's time to +migrate it to the top-level RTEMS git directory. First, the project directory +needs to be copied and then the permissions need to be set, so that everyone can +push into that repository. + +.. code-block:: shell + + cp -R /data/git/user/my-rtems-project.git /data/git + cd /data/git/my-rtems-project.git + chgrp -R gitrw ./ + chmod -R g+rws ./ + +Then copy the post-receive script from the rtems.git directory and change the +name of REPO. + +.. code-block:: shell + + cp /data/git/rtems.git/hooks/post-receive /data/git/my-rtems-project.git/hooks/ + +After making the change the post-receive script in the new repository should +look like this + +.. code-block:: shell + + #!/bin/sh + # + # The "post-receive" script is run after receive-pack has accepted a pack + # and the repository has been updated. It is passed arguments in through + # stdin in the form + # + # For example: + # aa453216d1b3e49e7f6f98441fa56946ddcd6a20 68f7abf4e6f922807889f52bc043ecd31b79f814 refs/heads/master + # + + REPO=my-rtems-project + + . /data/support/git-support/hooks/post-receive-0 + . /data/support/git-support/hooks/post-receive-1 + #. /data/support/git-support/hooks/post-receive-2 + . /data/support/git-support/hooks/post-receive-3 + . /data/support/git-support/hooks/post-receive-4 + . /data/support/git-support/hooks/post-receive-5 + GIT Push Configuration -- -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] cpukit/libmisc/monitor: Fix src/dest overlap of strcpy in mon-editor.c
On Fri, May 28, 2021 at 1:08 PM Joel Sherrill wrote:
>
> This looks OK.
Pushed. Thanks.
>
> On Thu, May 27, 2021 at 7:32 PM Harrison Edward Gerber
> wrote:
>>
>> From: Harrison Edward Gerber
>>
>> See also CID 1399727
>>
>> Closes #
>> ---
>> cpukit/libmisc/monitor/mon-editor.c | 12 +++-
>> 1 file changed, 11 insertions(+), 1 deletion(-)
>>
>> diff --git a/cpukit/libmisc/monitor/mon-editor.c
>> b/cpukit/libmisc/monitor/mon-editor.c
>> index dcea9fcc69..4287b399a5 100644
>> --- a/cpukit/libmisc/monitor/mon-editor.c
>> +++ b/cpukit/libmisc/monitor/mon-editor.c
>> @@ -360,7 +360,17 @@ rtems_monitor_line_editor (
>> {
>>int bs;
>>pos--;
>> - strcpy (buffer + pos, buffer + pos + 1);
>> +
>> + /*
>> + * Memory operation used here instead of string
>> + * method due the src and dest of buffer overlapping.
>> + */
>> + memmove(
>> +buffer + pos,
>> +buffer + pos + 1,
>> +RTEMS_COMMAND_BUFFER_SIZE - pos - 1
>> + );
>> + buffer[RTEMS_COMMAND_BUFFER_SIZE - 1] = '\0';
>>fprintf(stdout,"\b%s \b", buffer + pos);
>>for (bs = 0; bs < ((int) strlen (buffer) - pos); bs++)
>> putchar ('\b');
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2 3/3] main_help.c: Do not care what char is returned by getchar()
Hi all,
On Fri, May 28, 2021, 08:54 Gedare Bloom wrote:
> Are these three still pending? If so, can you ping the other 2 or
> advise what is blocking?
>
> On Mon, Apr 5, 2021 at 7:28 AM Ryan Long wrote:
> >
> > CID 1437650: Unchecked return value from library in rtems_shell_help().
> >
> > Closes #4291
> > ---
> > cpukit/libmisc/shell/main_help.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/cpukit/libmisc/shell/main_help.c
> b/cpukit/libmisc/shell/main_help.c
> > index 9f59e9d..564bc30 100644
> > --- a/cpukit/libmisc/shell/main_help.c
> > +++ b/cpukit/libmisc/shell/main_help.c
> > @@ -148,7 +148,7 @@ static int rtems_shell_help(
> > line+= rtems_shell_help_cmd(shell_cmd);
> >if (lines && (line > lines)) {
> > printf("Press any key to continue...");
>
Unrelated to this patch, but shouldn't the above line say "Press ENTER to
continue"? :D
> -getchar();
> > +(void) getchar();
> > printf("\n");
> > line = 0;
> >}
> > --
> > 1.8.3.1
> >
> > ___
> > devel mailing list
> > devel@rtems.org
> > http://lists.rtems.org/mailman/listinfo/devel
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
>
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] cpukit/libpci: fix potential buffer overflow in pci_cfg_print_code.c
Hi,
On Wed, May 26, 2021 at 2:45 PM Joel Sherrill wrote:
>
>
>
> On Wed, May 26, 2021 at 1:58 PM Harrison Edward Gerber
> wrote:
>>
>> See also CID 1399721
>> Closes #4442
>
>
> Blank line between these.
>
> But otherwise I think this looks good.
>
I pushed it with the added blank line in the commit message.
Thanks.
> Gedare... this looks like a good paper on this family of methods for
> advice on safe programming:
>
> https://www.sudo.ws/todd/papers/strlcpy.html
>
> Should we put a discussion of this type of issue in the Coding Style
> and reference it?
>
>>
>> ---
>> cpukit/libpci/pci_cfg_print_code.c | 4 ++--
>> 1 file changed, 2 insertions(+), 2 deletions(-)
>>
>> diff --git a/cpukit/libpci/pci_cfg_print_code.c
>> b/cpukit/libpci/pci_cfg_print_code.c
>> index e758fa661a..e0979db74a 100644
>> --- a/cpukit/libpci/pci_cfg_print_code.c
>> +++ b/cpukit/libpci/pci_cfg_print_code.c
>> @@ -65,8 +65,8 @@ static void pci_cfg_print_device(struct pci_dev *dev, char
>> *prefix)
>> char name[32];
>> char buf[8];
>> printf("%s.resources = {\n", prefix);
>> - strcpy(buf, prefix);
>> - strcat(buf, "\t");
>> + strlcpy(buf, prefix, sizeof(buf));
>> + strlcat(buf, "\t", sizeof(buf));
>> pci_cfg_print_resources(dev->resources, buf);
>> printf("%s},\n", prefix);
>> if (dev->next == NULL) {
>> --
>> 2.25.1
>>
>> ___
>> devel mailing list
>> devel@rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>
> ___
> devel mailing list
> devel@rtems.org
> http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check
On Thu, May 20, 2021 at 9:57 PM Gedare Bloom wrote:
>
> Well, since you pushed 2/2, you should push 1/2 (unless there are
> different patch series?)
>
Pushed.
> We should prefer to review and merge all/none of a series.
>
Ok, Understood. Thanks.
> On Thu, May 20, 2021 at 9:56 PM Gedare Bloom wrote:
> >
> > Seems fine by me, but wait until Monday to let anyone complain if they want.
> >
> > On Thu, May 20, 2021 at 5:35 PM Vijay Kumar Banerjee
> > wrote:
> > >
> > > Hi,
> > >
> > >
> > > On Thu, Apr 22, 2021 at 12:21 PM Gedare Bloom wrote:
> > > >
> > > > I guess there's not much else to do here without a network stack API
> > > > to manipulate the network task(s).
> > > >
> > > > Is there a ticket to fix the lack of ability to configure and access
> > > > network task priorities? I'm guessing libbsd and lwip will both need
> > > > to figure out how to do this somehow. The design isn't obvious to me
> > > > right now.
> > > >
> > >
> > > I somehow missed this before.
> > > I raised a ticket: https://devel.rtems.org/ticket/4436
> > > Is this ok to be pushed with this ticked number mentioned in the comment?
> > >
> > >
> > > Best regards,
> > > Vijay
> > >
> > > > On Thu, Apr 22, 2021 at 12:07 PM Vijay Kumar Banerjee
> > > > wrote:
> > > > >
> > > > > Ping :)
> > > > >
> > > > > On Tue, Apr 13, 2021 at 11:45 PM Vijay Kumar Banerjee
> > > > > wrote:
> > > > > >
> > > > > > Set the priority manually to make telnetd compatible with the
> > > > > > ---
> > > > > > cpukit/telnetd/telnetd.c | 11 +--
> > > > > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > > > > >
> > > > > > diff --git a/cpukit/telnetd/telnetd.c b/cpukit/telnetd/telnetd.c
> > > > > > index b8adec297a..7dad2f2f92 100644
> > > > > > --- a/cpukit/telnetd/telnetd.c
> > > > > > +++ b/cpukit/telnetd/telnetd.c
> > > > > > @@ -58,10 +58,6 @@
> > > > > > #include
> > > > > > #include
> > > > > >
> > > > > > -#ifdef RTEMS_NETWORKING
> > > > > > -#include
> > > > > > -#endif
> > > > > > -
> > > > > > #define TELNETD_EVENT_SUCCESS RTEMS_EVENT_0
> > > > > >
> > > > > > #define TELNETD_EVENT_ERROR RTEMS_EVENT_1
> > > > > > @@ -400,12 +396,7 @@ rtems_status_code rtems_telnetd_start(const
> > > > > > rtems_telnetd_config_table* config)
> > > > > >ctx->server_socket = -1;
> > > > > >LIST_INIT(>free_sessions);
> > > > > >
> > > > > > - /* Check priority */
> > > > > > -#ifdef RTEMS_NETWORKING
> > > > > > - if (ctx->config.priority == 0) {
> > > > > > -ctx->config.priority =
> > > > > > rtems_bsdnet_config.network_task_priority;
> > > > > > - }
> > > > > > -#endif
> > > > > > + /* Set priority */
> > > > > >if (ctx->config.priority == 0) {
> > > > > > ctx->config.priority = 100;
> > > > > >}
> > > > > > --
> > > > > > 2.26.2
> > > > > >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems v2] testsuites: Remove telnetd01
On Thu, May 20, 2021 at 5:49 PM Joel Sherrill wrote:
>
> Sure. Push it.
>
Thanks. Pushed.
> On Thu, May 20, 2021, 6:36 PM Vijay Kumar Banerjee wrote:
>>
>> Hi,
>>
>> In the last review, the commit message wasn't clear, I fixed it in this
>> version.
>> Does this look Ok to be merged?
>>
>> Best regards,
>> Vijay
>>
>> On Thu, Apr 22, 2021 at 8:02 PM Vijay Kumar Banerjee wrote:
>> >
>> > telnetd01 test cannot be run without a network stack, so this test is being
>> > moved to the rtems-net-legacy repository.
>> > ---
>> > spec/build/testsuites/libtests/grp.yml | 2 -
>> > spec/build/testsuites/libtests/telnetd01.yml | 22
>> > testsuites/libtests/telnetd01/init.c | 120 ---
>> > testsuites/libtests/telnetd01/telnetd01.doc | 24
>> > testsuites/libtests/telnetd01/telnetd01.scn | 11 --
>> > 5 files changed, 179 deletions(-)
>> > delete mode 100644 spec/build/testsuites/libtests/telnetd01.yml
>> > delete mode 100644 testsuites/libtests/telnetd01/init.c
>> > delete mode 100644 testsuites/libtests/telnetd01/telnetd01.doc
>> > delete mode 100644 testsuites/libtests/telnetd01/telnetd01.scn
>> >
>> > diff --git a/spec/build/testsuites/libtests/grp.yml
>> > b/spec/build/testsuites/libtests/grp.yml
>> > index 5695fc7f06..20a593a5d3 100644
>> > --- a/spec/build/testsuites/libtests/grp.yml
>> > +++ b/spec/build/testsuites/libtests/grp.yml
>> > @@ -258,8 +258,6 @@ links:
>> >uid: tar02
>> > - role: build-dependency
>> >uid: tar03
>> > -- role: build-dependency
>> > - uid: telnetd01
>> > - role: build-dependency
>> >uid: termios
>> > - role: build-dependency
>> > diff --git a/spec/build/testsuites/libtests/telnetd01.yml
>> > b/spec/build/testsuites/libtests/telnetd01.yml
>> > deleted file mode 100644
>> > index 9f5bda84d9..00
>> > --- a/spec/build/testsuites/libtests/telnetd01.yml
>> > +++ /dev/null
>> > @@ -1,22 +0,0 @@
>> > -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
>> > -build-type: test-program
>> > -cflags: []
>> > -copyrights:
>> > -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
>> > -cppflags: []
>> > -cxxflags: []
>> > -enabled-by:
>> > -- RTEMS_NETWORKING
>> > -features: c cprogram
>> > -includes:
>> > -- cpukit/libnetworking
>> > -ldflags: []
>> > -links: []
>> > -source:
>> > -- testsuites/libtests/telnetd01/init.c
>> > -stlib: []
>> > -target: testsuites/libtests/telnetd01.exe
>> > -type: build
>> > -use-after:
>> > -- telnetd
>> > -use-before: []
>> > diff --git a/testsuites/libtests/telnetd01/init.c
>> > b/testsuites/libtests/telnetd01/init.c
>> > deleted file mode 100644
>> > index a17126bf41..00
>> > --- a/testsuites/libtests/telnetd01/init.c
>> > +++ /dev/null
>> > @@ -1,120 +0,0 @@
>> > -/*
>> > - * Copyright (c) 2018 embedded brains GmbH. All rights reserved.
>> > - *
>> > - * embedded brains GmbH
>> > - * Dornierstr. 4
>> > - * 82178 Puchheim
>> > - * Germany
>> > - *
>> > - *
>> > - * The license and distribution terms for this file may be
>> > - * found in the file LICENSE in this distribution or at
>> > - * http://www.rtems.org/license/LICENSE.
>> > - */
>> > -
>> > -#ifdef HAVE_CONFIG_H
>> > -#include "config.h"
>> > -#endif
>> > -
>> > -#include
>> > -#include
>> > -#include
>> > -
>> > -#include
>> > -#include
>> > -#include
>> > -
>> > -#include
>> > -
>> > -const char rtems_test_name[] = "TELNETD 1";
>> > -
>> > -struct rtems_bsdnet_config rtems_bsdnet_config;
>> > -
>> > -static void command(char *device_name, void *arg)
>> > -{
>> > -}
>> > -
>> > -static void test_command_null(void)
>> > -{
>> > - static const rtems_telnetd_config_table config = {
>> > -.command = NULL
>> > - };
>> > - rtems_status_code sc;
>> > -
>> > - sc = rtems_telnetd_start();
>> > - rtems_test_assert(sc == RTEMS_INVALID_ADDRESS);
>> > -}
>> > -
>> > -static void tes
Re: [PATCH rtems v2] testsuites: Remove telnetd01
Hi,
In the last review, the commit message wasn't clear, I fixed it in this version.
Does this look Ok to be merged?
Best regards,
Vijay
On Thu, Apr 22, 2021 at 8:02 PM Vijay Kumar Banerjee wrote:
>
> telnetd01 test cannot be run without a network stack, so this test is being
> moved to the rtems-net-legacy repository.
> ---
> spec/build/testsuites/libtests/grp.yml | 2 -
> spec/build/testsuites/libtests/telnetd01.yml | 22
> testsuites/libtests/telnetd01/init.c | 120 ---
> testsuites/libtests/telnetd01/telnetd01.doc | 24
> testsuites/libtests/telnetd01/telnetd01.scn | 11 --
> 5 files changed, 179 deletions(-)
> delete mode 100644 spec/build/testsuites/libtests/telnetd01.yml
> delete mode 100644 testsuites/libtests/telnetd01/init.c
> delete mode 100644 testsuites/libtests/telnetd01/telnetd01.doc
> delete mode 100644 testsuites/libtests/telnetd01/telnetd01.scn
>
> diff --git a/spec/build/testsuites/libtests/grp.yml
> b/spec/build/testsuites/libtests/grp.yml
> index 5695fc7f06..20a593a5d3 100644
> --- a/spec/build/testsuites/libtests/grp.yml
> +++ b/spec/build/testsuites/libtests/grp.yml
> @@ -258,8 +258,6 @@ links:
>uid: tar02
> - role: build-dependency
>uid: tar03
> -- role: build-dependency
> - uid: telnetd01
> - role: build-dependency
>uid: termios
> - role: build-dependency
> diff --git a/spec/build/testsuites/libtests/telnetd01.yml
> b/spec/build/testsuites/libtests/telnetd01.yml
> deleted file mode 100644
> index 9f5bda84d9..00
> --- a/spec/build/testsuites/libtests/telnetd01.yml
> +++ /dev/null
> @@ -1,22 +0,0 @@
> -SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
> -build-type: test-program
> -cflags: []
> -copyrights:
> -- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
> -cppflags: []
> -cxxflags: []
> -enabled-by:
> -- RTEMS_NETWORKING
> -features: c cprogram
> -includes:
> -- cpukit/libnetworking
> -ldflags: []
> -links: []
> -source:
> -- testsuites/libtests/telnetd01/init.c
> -stlib: []
> -target: testsuites/libtests/telnetd01.exe
> -type: build
> -use-after:
> -- telnetd
> -use-before: []
> diff --git a/testsuites/libtests/telnetd01/init.c
> b/testsuites/libtests/telnetd01/init.c
> deleted file mode 100644
> index a17126bf41..00
> --- a/testsuites/libtests/telnetd01/init.c
> +++ /dev/null
> @@ -1,120 +0,0 @@
> -/*
> - * Copyright (c) 2018 embedded brains GmbH. All rights reserved.
> - *
> - * embedded brains GmbH
> - * Dornierstr. 4
> - * 82178 Puchheim
> - * Germany
> - *
> - *
> - * The license and distribution terms for this file may be
> - * found in the file LICENSE in this distribution or at
> - * http://www.rtems.org/license/LICENSE.
> - */
> -
> -#ifdef HAVE_CONFIG_H
> -#include "config.h"
> -#endif
> -
> -#include
> -#include
> -#include
> -
> -#include
> -#include
> -#include
> -
> -#include
> -
> -const char rtems_test_name[] = "TELNETD 1";
> -
> -struct rtems_bsdnet_config rtems_bsdnet_config;
> -
> -static void command(char *device_name, void *arg)
> -{
> -}
> -
> -static void test_command_null(void)
> -{
> - static const rtems_telnetd_config_table config = {
> -.command = NULL
> - };
> - rtems_status_code sc;
> -
> - sc = rtems_telnetd_start();
> - rtems_test_assert(sc == RTEMS_INVALID_ADDRESS);
> -}
> -
> -static void test_cannot_start_server_task(void)
> -{
> - static const rtems_telnetd_config_table config = {
> -.command = command,
> -.priority = UINT32_MAX
> - };
> - rtems_status_code sc;
> -
> - sc = rtems_telnetd_start();
> - rtems_test_assert(sc == RTEMS_UNSATISFIED);
> -}
> -
> -static void test_successful_start(void)
> -{
> - static const rtems_telnetd_config_table config = {
> -.command = command,
> -.stack_size = RTEMS_MINIMUM_STACK_SIZE
> - };
> - rtems_status_code sc;
> -
> - sc = rtems_telnetd_start();
> - rtems_test_assert(sc == RTEMS_SUCCESSFUL);
> -}
> -
> -static void test_already_started(void)
> -{
> - static const rtems_telnetd_config_table config = {
> -.command = command
> - };
> - rtems_status_code sc;
> -
> - sc = rtems_telnetd_start();
> - rtems_test_assert(sc == RTEMS_RESOURCE_IN_USE);
> -}
> -
> -static rtems_task Init(rtems_task_argument argument)
> -{
> - int rv;
> -
> - TEST_BEGIN();
> -
> - rv = rtems_bsdnet_initialize_network();
> - rtems_test_assert(rv == 0);
> -
> - test_command_null();
> - test_cannot_start_server_task();
> - test_successful_start();
> -
Re: [PATCH rtems 1/2] telnetd.c: Remove RTEMS_NETWORKING check
Hi,
On Thu, Apr 22, 2021 at 12:21 PM Gedare Bloom wrote:
>
> I guess there's not much else to do here without a network stack API
> to manipulate the network task(s).
>
> Is there a ticket to fix the lack of ability to configure and access
> network task priorities? I'm guessing libbsd and lwip will both need
> to figure out how to do this somehow. The design isn't obvious to me
> right now.
>
I somehow missed this before.
I raised a ticket: https://devel.rtems.org/ticket/4436
Is this ok to be pushed with this ticked number mentioned in the comment?
Best regards,
Vijay
> On Thu, Apr 22, 2021 at 12:07 PM Vijay Kumar Banerjee wrote:
> >
> > Ping :)
> >
> > On Tue, Apr 13, 2021 at 11:45 PM Vijay Kumar Banerjee
> > wrote:
> > >
> > > Set the priority manually to make telnetd compatible with the
> > > ---
> > > cpukit/telnetd/telnetd.c | 11 +--
> > > 1 file changed, 1 insertion(+), 10 deletions(-)
> > >
> > > diff --git a/cpukit/telnetd/telnetd.c b/cpukit/telnetd/telnetd.c
> > > index b8adec297a..7dad2f2f92 100644
> > > --- a/cpukit/telnetd/telnetd.c
> > > +++ b/cpukit/telnetd/telnetd.c
> > > @@ -58,10 +58,6 @@
> > > #include
> > > #include
> > >
> > > -#ifdef RTEMS_NETWORKING
> > > -#include
> > > -#endif
> > > -
> > > #define TELNETD_EVENT_SUCCESS RTEMS_EVENT_0
> > >
> > > #define TELNETD_EVENT_ERROR RTEMS_EVENT_1
> > > @@ -400,12 +396,7 @@ rtems_status_code rtems_telnetd_start(const
> > > rtems_telnetd_config_table* config)
> > >ctx->server_socket = -1;
> > >LIST_INIT(>free_sessions);
> > >
> > > - /* Check priority */
> > > -#ifdef RTEMS_NETWORKING
> > > - if (ctx->config.priority == 0) {
> > > -ctx->config.priority = rtems_bsdnet_config.network_task_priority;
> > > - }
> > > -#endif
> > > + /* Set priority */
> > >if (ctx->config.priority == 0) {
> > > ctx->config.priority = 100;
> > >}
> > > --
> > > 2.26.2
> > >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: while running rtems-test with coverage
(Resending for the list)
On Sun, May 16, 2021 at 10:18 AM Vijay Kumar Banerjee
wrote:
>
> Hi Mohammadreza,
>
> Sorry for the delay in replying :)
>
>
> On Tue, May 11, 2021 at 11:39 AM mohammadreza tahzibi
> wrote:
> >
> > Dear Sir
> > Hi,
> >
> > I am new in rtems and I am trying to run rtems-test ith enabling coverage.
> >
> Great.
>
> > But after many attempts I encountered the same problem and I am not able to
> > handle this issue.
> >
> > I would be glad if you could resolve this issue.
>
> please try --rtems-bsp=xilinx_zynq_a9_qemu-cov
>
> As a convention, there are two versions of the config for the targets
> that support coverage. The one with "-cov" suffix has the right
> configuration to use with `--coverage` option.
>
>
> Hope this helps.
>
> Best regards,
> Vijay
>
>
> > The error messages are attached below (atttachment).
> >
> > =
> > root@xen:/home/work/sandbox2# rtems/5/bin/rtems-test
> > --rtems-tools=/home/work/sandbox2/rtems/5/ --log=coverage-analysis.log
> > --rtems-bsp=xilinx_zynq_a9_qemu --target=arm-rtems5 --coverage
> > rtems-libbsd/build/arm-rtems5-xilinx_zynq_a9_qemu-default/selectpollkqueue01.exe
> > RTEMS Testing - Tester, 5 (d697769d4682 modified)
> > Traceback (most recent call last):
> > File "rtems/5/share/rtems/tester/rt/cmd-test.py", line 42, in
> > test.run(sys.argv[1:], command_path = base)
> > File "/home/work/sandbox2/rtems/5/share/rtems/tester/rt/test.py", line
> > 446, in run
> > trace = cov_trace)
> > File "/home/work/sandbox2/rtems/5/share/rtems/tester/rt/coverage.py",
> > line 385, in __init__
> > self.target = self.macros['target']
> > File "/home/work/sandbox2/rtems/5/share/rtems/rtemstoolkit/macros.py",
> > line 195, in __getitem__
> > raise IndexError('key: %s' % (key))
> > IndexError: key: target
> >
> >
> > =
> >
> >
> > Thank you for your assistance.
> > Regards
> >
> >
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] user/bld/index.rst: removed references to legacy network config options
Hi Harrison, I pushed this patch. https://git.rtems.org/rtems-docs/commit/?id=1f538688a7f743158e0e9e9bb673abd576307a0c Thanks, Vijay On Tue, May 11, 2021 at 7:28 PM Vijay Kumar Banerjee wrote: > > Hi Harrison, > > This patch looks good. If no one objects by Friday, I'll push this. Thanks. > > Best regards, > Vijay > > On Tue, May 11, 2021 at 7:16 PM Harrison Edward Gerber > wrote: > > > > --- > > user/bld/index.rst | 7 --- > > 1 file changed, 7 deletions(-) > > > > diff --git a/user/bld/index.rst b/user/bld/index.rst > > index ebedf5a..411b3a2 100644 > > --- a/user/bld/index.rst > > +++ b/user/bld/index.rst > > @@ -309,10 +309,6 @@ in the configuration file. > > Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP > > section of the configuration file. > > > > -``--enable-networking`` | ``--disable-networking`` > > -Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP > > section of > > -the configuration file. > > - > > ``--enable-paravirt`` | ``--disable-paravirt`` > > Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section > > of > > the configuration file. > > @@ -354,9 +350,6 @@ Please have a look at the following example > > configuration file. > > # --enable-multiprocessing > > RTEMS_MULTIPROCESSING = False > > > > -# --enable-networking > > -RTEMS_NETWORKING = True > > - > > # --disable-paravirt > > RTEMS_PARAVIRT = False > > > > -- > > 2.25.1 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] user/bld/index.rst: removed references to legacy network config options
Hi Harrison, This patch looks good. If no one objects by Friday, I'll push this. Thanks. Best regards, Vijay On Tue, May 11, 2021 at 7:16 PM Harrison Edward Gerber wrote: > > --- > user/bld/index.rst | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/user/bld/index.rst b/user/bld/index.rst > index ebedf5a..411b3a2 100644 > --- a/user/bld/index.rst > +++ b/user/bld/index.rst > @@ -309,10 +309,6 @@ in the configuration file. > Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP > section of the configuration file. > > -``--enable-networking`` | ``--disable-networking`` > -Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP section > of > -the configuration file. > - > ``--enable-paravirt`` | ``--disable-paravirt`` > Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section of > the configuration file. > @@ -354,9 +350,6 @@ Please have a look at the following example configuration > file. > # --enable-multiprocessing > RTEMS_MULTIPROCESSING = False > > -# --enable-networking > -RTEMS_NETWORKING = True > - > # --disable-paravirt > RTEMS_PARAVIRT = False > > -- > 2.25.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] user/bld/index.rst: removed references to legacy network config options
Hi Harrison, It's very close, just one little change On Fri, May 7, 2021 at 5:02 PM Harrison Gerber wrote: > > From: Harrison > As it was mentioned in your last review. Please use your full legal name in the patches for attribution purposes. Thank you for the patch. Best regards, Vijay > --- > user/bld/index.rst | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/user/bld/index.rst b/user/bld/index.rst > index ebedf5a..411b3a2 100644 > --- a/user/bld/index.rst > +++ b/user/bld/index.rst > @@ -309,10 +309,6 @@ in the configuration file. > Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP > section of the configuration file. > > -``--enable-networking`` | ``--disable-networking`` > -Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP section > of > -the configuration file. > - > ``--enable-paravirt`` | ``--disable-paravirt`` > Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section of > the configuration file. > @@ -354,9 +350,6 @@ Please have a look at the following example configuration > file. > # --enable-multiprocessing > RTEMS_MULTIPROCESSING = False > > -# --enable-networking > -RTEMS_NETWORKING = True > - > # --disable-paravirt > RTEMS_PARAVIRT = False > > -- > 2.25.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v3] bsps/shared/ofw: Fix coverity defects
On Thu, May 6, 2021 at 10:57 AM Gedare Bloom wrote:
>
> ok, Vijay please push
Pushed. Thanks.
>
> On Thu, May 6, 2021 at 2:06 AM G S Niteesh Babu wrote:
> >
> > This patch adds asserts to fix coverity defects
> > 1) CID 1474437 (Out-of-bounds access)
> > 2) CID 1474436 (Out-of-bounds access)
> >
> > From manual inspection, out of bounds access cannot occur due to
> > bounds checking but coverity fails to detect the checks.
> > We are adding asserts as a secondary check.
> > ---
> > bsps/shared/ofw/ofw.c | 12 +++-
> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >
> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> > index f4b8b63931..f7638b98ef 100644
> > --- a/bsps/shared/ofw/ofw.c
> > +++ b/bsps/shared/ofw/ofw.c
> > @@ -42,6 +42,7 @@
> > #include
> > #include
> > #include
> > +#include
> >
> > static void *fdtp = NULL;
> >
> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >const void *prop;
> >int offset;
> >int len;
> > + int copy_len;
> >uint32_t cpuid;
> >
> >offset = rtems_fdt_phandle_to_offset(node);
> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> > return -1;
> >}
> >
> > - bcopy(prop, buf, MIN(len, bufsize));
> > + copy_len = MIN(len, bufsize);
> > + _Assert(copy_len <= bufsize);
> > + memmove(buf, prop, copy_len);
> >
> >return len;
> > }
> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> > range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> > range.size = fdt32_to_cpu(ptr[j].size);
> >
> > +/**
> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> > + * address for buf[i]. If buf[i] points to any address larger
> > + * than this, it will be an out of bound access
> > + */
> > +_Assert([i] < (buf + size - (sizeof(buf[0]) - 1)));
> > if (buf[i].start >= range.child_bus &&
> > buf[i].start < range.child_bus + range.size) {
> >offset = range.parent_bus - range.child_bus;
> > --
> > 2.17.1
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH v2] bsps/shared/ofw: Fix coverity defects
Hi all,
On Wed, May 5, 2021 at 8:42 AM Gedare Bloom wrote:
>
> alright looks good. Vijay or Christian please confirm and push if
> you're good with it too.
>
ofw01.exe breaks after this patch. This probably needs some more debugging.
If it helps, I'm pasting the error:
```
*** FATAL ***
fatal source: 9 (RTEMS_FATAL_SOURCE_EXCEPTION)
R0 = 0x8001e68c R8 = 0x8001e68c
R1 = 0x80104641 R9 = 0x8005b90c
R2 = 0x0030 R10 = 0x80104640
R3 = 0x80104648 R11 = 0x0002
R4 = 0x0008 R12 = 0x8001e68b
R5 = 0x2ebc SP = 0x801045b8
R6 = 0x80104640 LR = 0x8000d720
R7 = 0x80101e28 PC = 0x80011ba8
CPSR = 0x8193 VEC = 0x0004
RTEMS version: 6.0.0.cfabe5d6e9d8b428110732fffb7ff6ee8211de04
RTEMS tools: 10.3.1 20210409 (RTEMS 6, RSB
4e256fc4cb0d91a098d2f3d88c3d302fc0426d56, Newlib 436e475)
executing thread ID: 0x089010001
executing thread name: IDLE
U-Boot SPL 2018.09-2-g0b54a51eee (Sep 10 2018 - 19:41:39 -0500)
Trying to boot from MMC2
Loading Environment from EXT4...
** Unable to use mmc 0:1 for loading the env **
```
Best regards,
Vijay
> On Wed, May 5, 2021 at 12:52 AM Niteesh G. S. wrote:
> >
> >
> >
> > On Mon, May 3, 2021 at 11:23 PM Gedare Bloom wrote:
> >>
> >> Hi Niteesh,
> >>
> >> This looks good to me. What/how did you test it?
> >
> > I tested it using the ofw01 test
> > https://git.rtems.org/rtems/tree/testsuites/libtests/ofw01/init.c
> > and read EEPROM using i2c.
> >
> >>
> >> Gedare
> >>
> >> On Sat, May 1, 2021 at 6:31 AM G S Niteesh Babu
> >> wrote:
> >> >
> >> > This patch adds asserts to fix coverity defects
> >> > 1) CID 1474437 (Out-of-bounds access)
> >> > 2) CID 1474436 (Out-of-bounds access)
> >> >
> >> > From manual inspection, out of bounds access cannot occur due to
> >> > bounds checking but coverity fails to detect the checks.
> >> > We are adding asserts as a secondary check.
> >> > ---
> >> > bsps/shared/ofw/ofw.c | 12 +++-
> >> > 1 file changed, 11 insertions(+), 1 deletion(-)
> >> >
> >> > diff --git a/bsps/shared/ofw/ofw.c b/bsps/shared/ofw/ofw.c
> >> > index f4b8b63931..0e0a7033ab 100644
> >> > --- a/bsps/shared/ofw/ofw.c
> >> > +++ b/bsps/shared/ofw/ofw.c
> >> > @@ -42,6 +42,7 @@
> >> > #include
> >> > #include
> >> > #include
> >> > +#include
> >> >
> >> > static void *fdtp = NULL;
> >> >
> >> > @@ -186,6 +187,7 @@ ssize_t rtems_ofw_get_prop(
> >> >const void *prop;
> >> >int offset;
> >> >int len;
> >> > + int copy_len;
> >> >uint32_t cpuid;
> >> >
> >> >offset = rtems_fdt_phandle_to_offset(node);
> >> > @@ -226,7 +228,9 @@ ssize_t rtems_ofw_get_prop(
> >> > return -1;
> >> >}
> >> >
> >> > - bcopy(prop, buf, MIN(len, bufsize));
> >> > + copy_len = MIN(len, bufsize);
> >> > + _Assert(copy_len <= bufsize);
> >> > + memmove(prop, buf, copy_len);
> >> >
> >> >return len;
> >> > }
> >> > @@ -637,6 +641,12 @@ int rtems_ofw_get_reg(
> >> > range.child_bus = fdt32_to_cpu(ptr[j].child_bus);
> >> > range.size = fdt32_to_cpu(ptr[j].size);
> >> >
> >> > +/**
> >> > + * (buf + size - (sizeof(buf[0]) - 1) is the last valid
> >> > + * address for buf[i]. If buf[i] points to any address larger
> >> > + * than this, it will be an out of bound access
> >> > + */
> >> > +_Assert([i] < (buf + size - (sizeof(buf[0]) - 1)));
> >> > if (buf[i].start >= range.child_bus &&
> >> > buf[i].start < range.child_bus + range.size) {
> >> >offset = range.parent_bus - range.child_bus;
> >> > --
> >> > 2.17.1
> >> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] Removed references to legacy network config options in user/bld/index.rst as those options are no longer valid
Hi Harrison, The patch looks good, just a little change is required. You'll notice that we follow a pattern in our commit messages. First, write the name of the file changed, then a short description of the change and then, if applicable, a longer description in the commit message. This message could be written as "user/bld/index.rst: short description here". Thanks for working on updating the documentation. Best regards, Vijay On Wed, May 5, 2021 at 3:23 PM Harrison Gerber wrote: > > From: Harrison > > --- > user/bld/index.rst | 7 --- > 1 file changed, 7 deletions(-) > > diff --git a/user/bld/index.rst b/user/bld/index.rst > index ebedf5a..411b3a2 100644 > --- a/user/bld/index.rst > +++ b/user/bld/index.rst > @@ -309,10 +309,6 @@ in the configuration file. > Set ``RTEMS_MULTIPROCESSING`` to ``True`` or ``False`` in the BSP > section of the configuration file. > > -``--enable-networking`` | ``--disable-networking`` > -Set ``RTEMS_NETWORKING`` to ``True`` or ``False`` in the BSP section > of > -the configuration file. > - > ``--enable-paravirt`` | ``--disable-paravirt`` > Set ``RTEMS_PARAVIRT`` to ``True`` or ``False`` in the BSP section of > the configuration file. > @@ -354,9 +350,6 @@ Please have a look at the following example configuration > file. > # --enable-multiprocessing > RTEMS_MULTIPROCESSING = False > > -# --enable-networking > -RTEMS_NETWORKING = True > - > # --disable-paravirt > RTEMS_PARAVIRT = False > > -- > 2.25.1 > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host
On Tue, May 4, 2021 at 1:01 AM Gedare Bloom wrote:
>
> looks good to me
>
Thanks. Pushed.
> On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote:
> >
> > Is this Ok to push?
> >
> > On Mon, Apr 19, 2021 at 11:32 AM Vijay Kumar Banerjee
> > wrote:
> > >
> > > On Mon, Apr 19, 2021 at 11:30 AM Vijay Kumar Banerjee
> > > wrote:
> > > >
> > > > ---
> > > > bsp_drivers.py | 22 +++---
> > > > 1 file changed, 11 insertions(+), 11 deletions(-)
> > > >
> > > > diff --git a/bsp_drivers.py b/bsp_drivers.py
> > > > index 3ca10c6..ec25c23 100644
> > > > --- a/bsp_drivers.py
> > > > +++ b/bsp_drivers.py
> > > > @@ -36,18 +36,18 @@ def bsp_files(bld):
> > > > include_dirs = {}
> > > > include_files = []
> > > >
> > > > -special_case_dirs = {'atsamv': './bsps/arm/atsam',
> > > > - 'lm32_evr': './bsps/lm32',
> > > > - 'lpc24xx_ea': './bsps/arm/shared/'}
> > > > +special_case_dirs = {'atsamv':
> > > > os.path.expanduser('bsps/arm/atsam'),
> > > > + 'lm32_evr': os.path.expanduser('bsps/lm32'),
> > > > + 'lpc24xx_ea':
> > > > os.path.expanduser('bsps/arm/shared/')}
> > > > special_case_sources = {'leon2':
> > > > -
> > > > ['./bsps/shared/grlib/net/network_interface_add.c',
> > > > - './bsps/shared/grlib/net/greth.c'],
> > > > +
> > > > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> > >
> > > I would like to add that these lines are over 80 characters limit.
> > >
> > > > +
> > > > os.path.expanduser('bsps/shared/grlib/net/greth.c')],
> > > > 'leon3':
> > > > -
> > > > ['./bsps/shared/grlib/net/network_interface_add.c',
> > > > - './bsps/shared/grlib/net/greth.c'],
> > > > +
> > > > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> > > > +
> > > > os.path.expanduser('bsps/shared/grlib/net/greth.c')],
> > > > 'griscv':
> > > > -
> > > > ['./bsps/shared/grlib/net/network_interface_add.c',
> > > > - './bsps/shared/grlib/net/greth.c']}
> > > > +
> > > > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> > > > +
> > > > os.path.expanduser('bsps/shared/grlib/net/greth.c')]}
> > > >
> > > > bsp_list = bld.env.RTEMS_ARCH_BSP_LIST
> > > >
> > > > @@ -57,7 +57,7 @@ def bsp_files(bld):
> > > > include_dirs[bsp] = []
> > > > source_files[bsp] = []
> > > > if bsp not in special_case_dirs:
> > > > -source_dir = os.walk(os.path.join('./bsps', arch, bsp))
> > > > +source_dir = os.walk(os.path.join('bsps', arch, bsp))
> > > > else:
> > > > source_dir = os.walk(special_case_dirs[bsp])
> > > > for root, dirs, files in source_dir:
> > > > @@ -70,5 +70,5 @@ def bsp_files(bld):
> > > > include_dirs[bsp].append(root)
> > > > if bsp in special_case_sources:
> > > > source_files[bsp].extend(special_case_sources[bsp])
> > > > -include_dirs[bsp].append(os.path.join('./bsps', arch, bsp,
> > > > 'net'))
> > > > +include_dirs[bsp].append(os.path.join('bsps', arch, bsp,
> > > > 'net'))
> > > > return (include_dirs, source_files)
> > > > --
> > > > 2.26.2
> > > >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems-net-legacy] Re-license copyright texts
On Tue, May 4, 2021 at 1:02 AM Gedare Bloom wrote: > > ok Pushed. Thanks. > > On Mon, May 3, 2021 at 4:37 PM Vijay Kumar Banerjee wrote: > > > > --- > > bsp_drivers.py | 3 ++- > > netlegacy.py| 3 ++- > > testsuites/ftp01/wscript| 3 ++- > > testsuites/loopback/wscript | 3 ++- > > testsuites/networking01/wscript | 3 ++- > > testsuites/pppd/wscript | 3 ++- > > testsuites/syscall01/wscript| 3 ++- > > testsuites/telnetd01/wscript| 3 ++- > > testsuites/wscript | 3 ++- > > wscript | 3 ++- > > 10 files changed, 20 insertions(+), 10 deletions(-) > > > > diff --git a/bsp_drivers.py b/bsp_drivers.py > > index ec25c23..bb31789 100644 > > --- a/bsp_drivers.py > > +++ b/bsp_drivers.py > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/netlegacy.py b/netlegacy.py > > index 4dd9e96..ebab745 100644 > > --- a/netlegacy.py > > +++ b/netlegacy.py > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/ftp01/wscript b/testsuites/ftp01/wscript > > index aa73d1b..200138e 100644 > > --- a/testsuites/ftp01/wscript > > +++ b/testsuites/ftp01/wscript > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/loopback/wscript b/testsuites/loopback/wscript > > index 60f863f..8ba0443 100644 > > --- a/testsuites/loopback/wscript > > +++ b/testsuites/loopback/wscript > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/networking01/wscript > > b/testsuites/networking01/wscript > > index 801f74f..f91a5f8 100644 > > --- a/testsuites/networking01/wscript > > +++ b/testsuites/networking01/wscript > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/pppd/wscript b/testsuites/pppd/wscript > > index 1f0e50d..cd57444 100644 > > --- a/testsuites/pppd/wscript > > +++ b/testsuites/pppd/wscript > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/syscall01/wscript b/testsuites/syscall01/wscript > > index 222c196..5ad2e19 100644 > > --- a/testsuites/syscall01/wscript > > +++ b/testsuites/syscall01/wscript > > @@ -1,7 +1,8 @@ > > # > > # RTEMS Project (https://www.rtems.org/) > > # > > -# Copyright (c) 2021 Vijay Kumar Banerjee . > > +# Copyright (c) 2021 Regents of University of Colorado > > +# Written by Vijay Kumar Banerjee . > > # All rights reserved. > > # > > # Redistribution and use in source and binary forms, with or without > > diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript &
[PATCH rtems-net-legacy] Re-license copyright texts
--- bsp_drivers.py | 3 ++- netlegacy.py| 3 ++- testsuites/ftp01/wscript| 3 ++- testsuites/loopback/wscript | 3 ++- testsuites/networking01/wscript | 3 ++- testsuites/pppd/wscript | 3 ++- testsuites/syscall01/wscript| 3 ++- testsuites/telnetd01/wscript| 3 ++- testsuites/wscript | 3 ++- wscript | 3 ++- 10 files changed, 20 insertions(+), 10 deletions(-) diff --git a/bsp_drivers.py b/bsp_drivers.py index ec25c23..bb31789 100644 --- a/bsp_drivers.py +++ b/bsp_drivers.py @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/netlegacy.py b/netlegacy.py index 4dd9e96..ebab745 100644 --- a/netlegacy.py +++ b/netlegacy.py @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/ftp01/wscript b/testsuites/ftp01/wscript index aa73d1b..200138e 100644 --- a/testsuites/ftp01/wscript +++ b/testsuites/ftp01/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/loopback/wscript b/testsuites/loopback/wscript index 60f863f..8ba0443 100644 --- a/testsuites/loopback/wscript +++ b/testsuites/loopback/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/networking01/wscript b/testsuites/networking01/wscript index 801f74f..f91a5f8 100644 --- a/testsuites/networking01/wscript +++ b/testsuites/networking01/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/pppd/wscript b/testsuites/pppd/wscript index 1f0e50d..cd57444 100644 --- a/testsuites/pppd/wscript +++ b/testsuites/pppd/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/syscall01/wscript b/testsuites/syscall01/wscript index 222c196..5ad2e19 100644 --- a/testsuites/syscall01/wscript +++ b/testsuites/syscall01/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/telnetd01/wscript b/testsuites/telnetd01/wscript index dc18737..f24f2ad 100644 --- a/testsuites/telnetd01/wscript +++ b/testsuites/telnetd01/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/testsuites/wscript b/testsuites/wscript index 11ff55a..5145e92 100644 --- a/testsuites/wscript +++ b/testsuites/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without diff --git a/wscript b/wscript index 7af317d..518108b 100644 --- a/wscript +++ b/wscript @@ -1,7 +1,8 @@ # # RTEMS Project (https://www.rtems.org/) # -# Copyright (c) 2021 Vijay Kumar Banerjee . +# Copyright (c) 2021 Regents of University of Colorado +# Written by Vijay Kumar Banerjee . # All rights reserved. # # Redistribution and use in source and binary forms, with or without -- 2.26.2 ___ devel
Re: [PATCH rtems-net-legacy v2] bsp_drivers: Use os.path for compatibility with non Unix host
Is this Ok to push?
On Mon, Apr 19, 2021 at 11:32 AM Vijay Kumar Banerjee wrote:
>
> On Mon, Apr 19, 2021 at 11:30 AM Vijay Kumar Banerjee wrote:
> >
> > ---
> > bsp_drivers.py | 22 +++---
> > 1 file changed, 11 insertions(+), 11 deletions(-)
> >
> > diff --git a/bsp_drivers.py b/bsp_drivers.py
> > index 3ca10c6..ec25c23 100644
> > --- a/bsp_drivers.py
> > +++ b/bsp_drivers.py
> > @@ -36,18 +36,18 @@ def bsp_files(bld):
> > include_dirs = {}
> > include_files = []
> >
> > -special_case_dirs = {'atsamv': './bsps/arm/atsam',
> > - 'lm32_evr': './bsps/lm32',
> > - 'lpc24xx_ea': './bsps/arm/shared/'}
> > +special_case_dirs = {'atsamv': os.path.expanduser('bsps/arm/atsam'),
> > + 'lm32_evr': os.path.expanduser('bsps/lm32'),
> > + 'lpc24xx_ea':
> > os.path.expanduser('bsps/arm/shared/')}
> > special_case_sources = {'leon2':
> > -
> > ['./bsps/shared/grlib/net/network_interface_add.c',
> > - './bsps/shared/grlib/net/greth.c'],
> > +
> > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
>
> I would like to add that these lines are over 80 characters limit.
>
> > +
> > os.path.expanduser('bsps/shared/grlib/net/greth.c')],
> > 'leon3':
> > -
> > ['./bsps/shared/grlib/net/network_interface_add.c',
> > - './bsps/shared/grlib/net/greth.c'],
> > +
> > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> > +
> > os.path.expanduser('bsps/shared/grlib/net/greth.c')],
> > 'griscv':
> > -
> > ['./bsps/shared/grlib/net/network_interface_add.c',
> > - './bsps/shared/grlib/net/greth.c']}
> > +
> > [os.path.expanduser('bsps/shared/grlib/net/network_interface_add.c'),
> > +
> > os.path.expanduser('bsps/shared/grlib/net/greth.c')]}
> >
> > bsp_list = bld.env.RTEMS_ARCH_BSP_LIST
> >
> > @@ -57,7 +57,7 @@ def bsp_files(bld):
> > include_dirs[bsp] = []
> > source_files[bsp] = []
> > if bsp not in special_case_dirs:
> > -source_dir = os.walk(os.path.join('./bsps', arch, bsp))
> > +source_dir = os.walk(os.path.join('bsps', arch, bsp))
> > else:
> > source_dir = os.walk(special_case_dirs[bsp])
> > for root, dirs, files in source_dir:
> > @@ -70,5 +70,5 @@ def bsp_files(bld):
> > include_dirs[bsp].append(root)
> > if bsp in special_case_sources:
> > source_files[bsp].extend(special_case_sources[bsp])
> > -include_dirs[bsp].append(os.path.join('./bsps', arch, bsp, 'net'))
> > +include_dirs[bsp].append(os.path.join('bsps', arch, bsp, 'net'))
> > return (include_dirs, source_files)
> > --
> > 2.26.2
> >
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Issues with rtems_waf on Windows 10 with gccdeps module
Hi Robin,
On Mon, May 3, 2021 at 6:37 AM Robin Müller
wrote:
>
> I also tried bld.path.find_or_declare('rtems.h') like in the supplied
example, but that did not work for me either.
>
That worked for me in multiple places before. not sure what's happening
there.
> Kind Regards
> Robin
>
> On Mon, 3 May 2021 at 14:31, Robin Müller
wrote:
>>
>> Hello Vijay,
>>
>> I tried bld.find_or_declare('rtems.h') but that did not work for me.
>>
>> Just out of curiosity, why was the patch not accepted? I did not find
anything in the waf gitlab.
>>
I couldn't find the gitlab link where Chris raised this issue in waf, but I
found the devel discussion after which I came up with the find_or_declare
solution. Maybe you could find something helpful from the discussion as
well:
https://lists.rtems.org/pipermail/devel/2020-April/059468.html
Best regards,
Vijay
>> Kind Regards
>> Robin
>>
>> On Sat, 1 May 2021 at 20:29, Vijay Kumar Banerjee
wrote:
>>>
>>> Hi Robin,
>>>
>>> On Fri, Apr 30, 2021 at 2:36 AM Robin Müller
wrote:
>>> >
>>> > Issue can be reproduced by doing the quickstart application build on
Windows 10. The issue are backslashes in the absolute paths of the
dependency paths
>>> > which were not stripped from dependency paths on Windows,
>>> > causing waf to not recognize them as valid absolute paths. More
specifically, I printed the resulting dependency paths after stripping
>>> >
>>> >
C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
>>> >
>>> > The backslash at the start causes the issue.
>>> > I was able to fix this with the following adaptations (gccdeps.py
starting line 108)
>>> >
>>> As I mentioned earlier, this patch will probably not be accepted in
>>> upstream waf and it might not be a great idea to change it in the
>>> RTEMS version of waf, since it'll cause issues in the future when we
>>> try to sync up with the waf updates from upstream.
>>>
>>> Please try bld.find_or_declare from your wscript and see if that fixes
>>> the header file not found issue. That is probably a cleaner solution
>>> for now.
>>>
>>> > # Now join all the lines together
>>> > txt = txt.replace('\\\n', '')
>>> >
>>> > val = txt.strip()
>>> > val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
>>> > # This was added to replace backslashes which can cause issues on
Windows
>>> > if os.name == 'nt':
>>> > val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val)
if x]
>>> > print(val)
>>> > nodes = []
>>> > bld = self.generator.bld
>>> >
>>> > I don't know whether this can have other evil side effects, but the
waf build works after that..
>>> The possible evil side effects could be the issue with "\", as you
>>> mentioned here. So better to avoid hacking it. :)
>>>
>>>
>>> Best regards,
>>> Vijay
>>> >
>>> > Kind Regards
>>> > Robin
>>> >
>>> > On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee
wrote:
>>> >>
>>> >> Hi all,
>>> >>
>>> >>
>>> >> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns wrote:
>>> >> >
>>> >> > On 30/4/21 5:01 am, Robin Müller wrote:
>>> >> > > Yes that is the prefix. The rtems.h file is definitely located
at the location
>>> >> > > in the warning and it works on older commit of rtems_waf (where
gccdeps.py is
>>> >> > > not used).
>>> >> > > I briefly looked through the gccdeps.py file and it is doing
some string
>>> >> > > stripping operations.
>>> >> > > Maybe that is the issue but I am not sure.
>>> >> >
>>> >> > Thank you for debugging this and I agree it look like something is
a little off
>>> >> > in gccdeps.
>>> >> >
>>> >> Yes, I had a patch for that but I think there was a discussion
>>> >> upstream between ita1024 and Chris and the conclusion was that the
>>> >> patch won't be accepted. I can't find it right now but I could fix
>>> >> this problem by using find_or_declare.
>>> >>
>>> >> @Robin: Please try to use the find function and see if it fixes.
>>> >> Here's an example that worked quite nicely in rtems-examples:
>>> >>
https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>>> >>
>>> >>
>>> >> Best regards,
>>> >> Vijay
>>> >>
>>> >> > I will need to try and reproduce this to have a chance of finding
it. What
>>> >> > happens if you remove gccdeps.py? Will that you get past this
point?
>>> >> >
>>> >> > Chris
>>> >> > ___
>>> >> > devel mailing list
>>> >> > devel@rtems.org
>>> >> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Issues with rtems_waf on Windows 10 with gccdeps module
Hi Robin,
On Fri, Apr 30, 2021 at 2:36 AM Robin Müller wrote:
>
> Issue can be reproduced by doing the quickstart application build on Windows
> 10. The issue are backslashes in the absolute paths of the dependency paths
> which were not stripped from dependency paths on Windows,
> causing waf to not recognize them as valid absolute paths. More specifically,
> I printed the resulting dependency paths after stripping
>
> C\:/Users/Robin/Documents/RTEMS/rtems-tools/rtems/6/sparc-rtems6/erc32/lib/include/rtems/userenv.h
>
> The backslash at the start causes the issue.
> I was able to fix this with the following adaptations (gccdeps.py starting
> line 108)
>
As I mentioned earlier, this patch will probably not be accepted in
upstream waf and it might not be a great idea to change it in the
RTEMS version of waf, since it'll cause issues in the future when we
try to sync up with the waf updates from upstream.
Please try bld.find_or_declare from your wscript and see if that fixes
the header file not found issue. That is probably a cleaner solution
for now.
> # Now join all the lines together
> txt = txt.replace('\\\n', '')
>
> val = txt.strip()
> val = [x.replace('\\ ', ' ') for x in re_splitter.split(val) if x]
> # This was added to replace backslashes which can cause issues on Windows
> if os.name == 'nt':
> val = [x.replace('C:\\', 'C:') for x in re_splitter.split(val) if x]
> print(val)
> nodes = []
> bld = self.generator.bld
>
> I don't know whether this can have other evil side effects, but the waf build
> works after that..
The possible evil side effects could be the issue with "\", as you
mentioned here. So better to avoid hacking it. :)
Best regards,
Vijay
>
> Kind Regards
> Robin
>
> On Fri, 30 Apr 2021 at 00:30, Vijay Kumar Banerjee wrote:
>>
>> Hi all,
>>
>>
>> On Thu, Apr 29, 2021 at 3:01 PM Chris Johns wrote:
>> >
>> > On 30/4/21 5:01 am, Robin Müller wrote:
>> > > Yes that is the prefix. The rtems.h file is definitely located at the
>> > > location
>> > > in the warning and it works on older commit of rtems_waf (where
>> > > gccdeps.py is
>> > > not used).
>> > > I briefly looked through the gccdeps.py file and it is doing some string
>> > > stripping operations.
>> > > Maybe that is the issue but I am not sure.
>> >
>> > Thank you for debugging this and I agree it look like something is a
>> > little off
>> > in gccdeps.
>> >
>> Yes, I had a patch for that but I think there was a discussion
>> upstream between ita1024 and Chris and the conclusion was that the
>> patch won't be accepted. I can't find it right now but I could fix
>> this problem by using find_or_declare.
>>
>> @Robin: Please try to use the find function and see if it fixes.
>> Here's an example that worked quite nicely in rtems-examples:
>> https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34
>>
>>
>> Best regards,
>> Vijay
>>
>> > I will need to try and reproduce this to have a chance of finding it. What
>> > happens if you remove gccdeps.py? Will that you get past this point?
>> >
>> > Chris
>> > ___
>> > devel mailing list
>> > devel@rtems.org
>> > http://lists.rtems.org/mailman/listinfo/devel
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Issues with rtems_waf on Windows 10 with gccdeps module
Hi all, On Thu, Apr 29, 2021 at 3:01 PM Chris Johns wrote: > > On 30/4/21 5:01 am, Robin Müller wrote: > > Yes that is the prefix. The rtems.h file is definitely located at the > > location > > in the warning and it works on older commit of rtems_waf (where gccdeps.py > > is > > not used). > > I briefly looked through the gccdeps.py file and it is doing some string > > stripping operations. > > Maybe that is the issue but I am not sure. > > Thank you for debugging this and I agree it look like something is a little > off > in gccdeps. > Yes, I had a patch for that but I think there was a discussion upstream between ita1024 and Chris and the conclusion was that the patch won't be accepted. I can't find it right now but I could fix this problem by using find_or_declare. @Robin: Please try to use the find function and see if it fixes. Here's an example that worked quite nicely in rtems-examples: https://git.rtems.org/rtems-examples/tree/filesystem/fat_ramdisk/wscript#n34 Best regards, Vijay > I will need to try and reproduce this to have a chance of finding it. What > happens if you remove gccdeps.py? Will that you get past this point? > > Chris > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH rtems] cpukit/Makefile.am: Remove remaining LIBNETWORKING files
On Thu, Apr 29, 2021 at 10:13 AM Gedare Bloom wrote: > > ok > Pushed. Thanks. > On Thu, Apr 29, 2021 at 10:07 AM Vijay Kumar Banerjee wrote: > > > > --- > > cpukit/Makefile.am | 43 --- > > cpukit/configure.ac | 1 - > > 2 files changed, 44 deletions(-) > > > > diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am > > index b0df610bed..44ab945778 100644 > > --- a/cpukit/Makefile.am > > +++ b/cpukit/Makefile.am > > @@ -1372,15 +1372,6 @@ librtemscpu_a_SOURCES += libmisc/shell/main_pci.c > > > > endif > > > > -if LIBNETWORKING > > - > > -librtemscpu_a_SOURCES += libmisc/shell/main_ifconfig.c > > -librtemscpu_a_SOURCES += libmisc/shell/main_route.c > > -librtemscpu_a_SOURCES += libmisc/shell/main_netstats.c > > -librtemscpu_a_SOURCES += libmisc/shell/main_ping.c > > - > > -endif > > - > > endif > > > > if LIBUTF8PROC > > @@ -1813,40 +1804,6 @@ libz_a_SOURCES += zlib/trees.c > > libz_a_SOURCES += zlib/uncompr.c > > libz_a_SOURCES += zlib/zutil.c > > > > -if LIBNETWORKING > > - > > -project_lib_LIBRARIES += libnfs.a > > - > > -libnfs_a_SOURCES = > > -libnfs_a_SOURCES += libfs/src/nfsclient/proto/mount_prot_xdr.c > > -libnfs_a_SOURCES += libfs/src/nfsclient/proto/nfs_prot_xdr.c > > -libnfs_a_SOURCES += libfs/src/nfsclient/src/nfs.c > > -libnfs_a_SOURCES += libfs/src/nfsclient/src/rpcio.c > > -libnfs_a_SOURCES += libfs/src/nfsclient/src/sock_mbuf.c > > -libnfs_a_SOURCES += libfs/src/nfsclient/src/xdr_mbuf.c > > - > > -project_lib_LIBRARIES += libpppd.a > > - > > -libpppd_a_SOURCES = > > -libpppd_a_SOURCES += pppd/auth.c > > -libpppd_a_SOURCES += pppd/ccp.c > > -libpppd_a_SOURCES += pppd/chap.c > > -libpppd_a_SOURCES += pppd/chap_ms.c > > -libpppd_a_SOURCES += pppd/chat.c > > -libpppd_a_SOURCES += pppd/demand.c > > -libpppd_a_SOURCES += pppd/fsm.c > > -libpppd_a_SOURCES += pppd/ipcp.c > > -libpppd_a_SOURCES += pppd/lcp.c > > -libpppd_a_SOURCES += pppd/magic.c > > -libpppd_a_SOURCES += pppd/options.c > > -libpppd_a_SOURCES += pppd/rtemsmain.c > > -libpppd_a_SOURCES += pppd/rtemspppd.c > > -libpppd_a_SOURCES += pppd/sys-rtems.c > > -libpppd_a_SOURCES += pppd/upap.c > > -libpppd_a_SOURCES += pppd/utils.c > > - > > -endif > > - > > if HACK_TO_AVOID_LONG_ARG_LIST > > > > librtemscpu.a: $(librtemscpu_a_OBJECTS) $(librtemscpu_a_DEPENDENCIES) > > $(EXTRA_librtemscpu_a_DEPENDENCIES) > > diff --git a/cpukit/configure.ac b/cpukit/configure.ac > > index 9c25c3770d..e3c039383c 100644 > > --- a/cpukit/configure.ac > > +++ b/cpukit/configure.ac > > @@ -293,7 +293,6 @@ AM_CONDITIONAL(HAS_MP,test x"$enable_multiprocessing" = > > x"yes" ) > > AM_CONDITIONAL(HAS_SMP,[test "$RTEMS_HAS_SMP" = "yes"]) > > > > AM_CONDITIONAL(HAS_PTHREADS,test x"$rtems_cv_HAS_POSIX_API" = x"yes") > > -AM_CONDITIONAL(LIBNETWORKING,test x"$rtems_cv_HAS_NETWORKING" = x"yes") > > > > AM_CONDITIONAL([LIBSHELL],[test x"$HAVE_ASSIGNABLE_STDIO" = x"yes"]) > > AM_CONDITIONAL([LIBSERDBG],[test x"$rtems_cv_cc_attribute_weak" = x"yes"]) > > -- > > 2.26.2 > > > > ___ > > devel mailing list > > devel@rtems.org > > http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] cpukit/Makefile.am: Remove remaining LIBNETWORKING files
--- cpukit/Makefile.am | 43 --- cpukit/configure.ac | 1 - 2 files changed, 44 deletions(-) diff --git a/cpukit/Makefile.am b/cpukit/Makefile.am index b0df610bed..44ab945778 100644 --- a/cpukit/Makefile.am +++ b/cpukit/Makefile.am @@ -1372,15 +1372,6 @@ librtemscpu_a_SOURCES += libmisc/shell/main_pci.c endif -if LIBNETWORKING - -librtemscpu_a_SOURCES += libmisc/shell/main_ifconfig.c -librtemscpu_a_SOURCES += libmisc/shell/main_route.c -librtemscpu_a_SOURCES += libmisc/shell/main_netstats.c -librtemscpu_a_SOURCES += libmisc/shell/main_ping.c - -endif - endif if LIBUTF8PROC @@ -1813,40 +1804,6 @@ libz_a_SOURCES += zlib/trees.c libz_a_SOURCES += zlib/uncompr.c libz_a_SOURCES += zlib/zutil.c -if LIBNETWORKING - -project_lib_LIBRARIES += libnfs.a - -libnfs_a_SOURCES = -libnfs_a_SOURCES += libfs/src/nfsclient/proto/mount_prot_xdr.c -libnfs_a_SOURCES += libfs/src/nfsclient/proto/nfs_prot_xdr.c -libnfs_a_SOURCES += libfs/src/nfsclient/src/nfs.c -libnfs_a_SOURCES += libfs/src/nfsclient/src/rpcio.c -libnfs_a_SOURCES += libfs/src/nfsclient/src/sock_mbuf.c -libnfs_a_SOURCES += libfs/src/nfsclient/src/xdr_mbuf.c - -project_lib_LIBRARIES += libpppd.a - -libpppd_a_SOURCES = -libpppd_a_SOURCES += pppd/auth.c -libpppd_a_SOURCES += pppd/ccp.c -libpppd_a_SOURCES += pppd/chap.c -libpppd_a_SOURCES += pppd/chap_ms.c -libpppd_a_SOURCES += pppd/chat.c -libpppd_a_SOURCES += pppd/demand.c -libpppd_a_SOURCES += pppd/fsm.c -libpppd_a_SOURCES += pppd/ipcp.c -libpppd_a_SOURCES += pppd/lcp.c -libpppd_a_SOURCES += pppd/magic.c -libpppd_a_SOURCES += pppd/options.c -libpppd_a_SOURCES += pppd/rtemsmain.c -libpppd_a_SOURCES += pppd/rtemspppd.c -libpppd_a_SOURCES += pppd/sys-rtems.c -libpppd_a_SOURCES += pppd/upap.c -libpppd_a_SOURCES += pppd/utils.c - -endif - if HACK_TO_AVOID_LONG_ARG_LIST librtemscpu.a: $(librtemscpu_a_OBJECTS) $(librtemscpu_a_DEPENDENCIES) $(EXTRA_librtemscpu_a_DEPENDENCIES) diff --git a/cpukit/configure.ac b/cpukit/configure.ac index 9c25c3770d..e3c039383c 100644 --- a/cpukit/configure.ac +++ b/cpukit/configure.ac @@ -293,7 +293,6 @@ AM_CONDITIONAL(HAS_MP,test x"$enable_multiprocessing" = x"yes" ) AM_CONDITIONAL(HAS_SMP,[test "$RTEMS_HAS_SMP" = "yes"]) AM_CONDITIONAL(HAS_PTHREADS,test x"$rtems_cv_HAS_POSIX_API" = x"yes") -AM_CONDITIONAL(LIBNETWORKING,test x"$rtems_cv_HAS_NETWORKING" = x"yes") AM_CONDITIONAL([LIBSHELL],[test x"$HAVE_ASSIGNABLE_STDIO" = x"yes"]) AM_CONDITIONAL([LIBSERDBG],[test x"$rtems_cv_cc_attribute_weak" = x"yes"]) -- 2.26.2 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: tcpreplay for testing network stacks
On Wed, Apr 28, 2021 at 3:27 PM Chris Johns wrote: > > > > On 29/4/21 3:00 am, Vijay Kumar Banerjee wrote: > > On Wed, Apr 28, 2021 at 10:49 AM Christian Mauderer > > wrote: > >> > >> Hello Vijay, > >> > >> On 28/04/2021 18:25, Vijay Kumar Banerjee wrote: > >>> On Wed, Apr 28, 2021 at 12:41 AM Christian MAUDERER > >>> wrote: > >>>> > >>>> Hello Vijay, > >>>> > >>>> Am 27.04.21 um 18:48 schrieb Vijay Kumar Banerjee: > >>>>> Hi, > >>>>> > >>>>> I came across the tcpreplay tool and it looks like a nice tool for > >>>>> testing the network stacks. It can be used to capture network traffic > >>>>> and then play it back, this will help with testing the network packets > >>>>> from different network stacks. > >>>> > >>>> Sounds like an interesting tool. > >>>> > >>>>> > >>>>> My proposal is to add the tcpreply as a host-side tool in rtems-tools > >>>>> and use it with the network interface where the network application is > >>>>> running. The only issue that I see with the whole idea is that the > >>>>> tcpreplay is GPLv3 licensed. Will that be compatible for rtems-tools? > >>>>> The github repository says that it's compatible with UNIX and Windows > >>>>> with cygwin. > >>>> > >>>> The more difficult problem could be the missing Mac and FreeBSD support. > >>>> > >>> That's a good point. > >>> > >>>> What would be the advantage of having tcpreply in rtems-tools? Do you > >>>> want to use it for automated tests? > >>>> > >>> Yes. I was thinking about capturing the pcap format packets in > >>> temporary files and then running tcpreplay to check for any network > >>> issues. I haven't planned exactly how that will be implemented but > >>> roughly this is the idea. > >>> > >> > >> In what form would you automate that? Some test case in RTEMS or some > >> special repository? I assume that you need some special setup for > >> specific (simulator) targets anyway, don't you? So a general purpose > >> test for all targets will be difficult. > >> > > I was not thinking about a special repository. It would be nice to > > have it as test case or as an rtems-test config where the script will > > capture the packets and feed them to tcpreplay. > > Capture from where? How do these traces deal with the differences in networks? more tools :). What I was attempting is tcpdump to get the pcap and then tcpreplay. I was basically in search of some way to effectively test the network stacks. > Does tcpreply rewrite various fields, for example a DHCP server response? I > suspect it does not. > I'm not sure. > Tcpreplay may work out to be a good tool we use but I think there needs to be > some more ground work to see if you can "virtualize" a network. If you can do > this you control the arena the devices operate in and all the characteristics > and then play back would be possible and portable. > > VDE may be an interesting part of this. I seem to remember it has a DHCP > server > so if you use this with a tap that VDE manages rtems-test could use that > interface. > That sounds like a great idea. > A tricky area to look into is if a VDE port can map to a physical port? If > this > can be done you could mix simulation and real hardware and that would be > amazing > to have. > I'll search about this. Thanks for the great ideas, I'm indeed getting some direction. Best regards, Vijay > >> If it is about testing the stacks and not the drivers, it might would be > >> possible to write some kind of dummy network driver that can read pcap > >> format (or some other raw packet format) directly and hands the packets > >> to the network stack. Such a driver maybe could even provide packets to > >> a test frame again so that you can check responses. > >> > > The objective is to test the stacks. The dummy network driver sounds > > like a great idea, thanks. I'll explore this direction more. > > I prefer real drivers are used as it lets us extend testing to VLAN and > multicast (driver hashes and filter testing). > > A solution needs to find a suitable lowest common denominator. This means > hardware and simulation and possibly the different networking stack options > we have. > > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: tcpreplay for testing network stacks
On Wed, Apr 28, 2021 at 3:26 PM Chris Johns wrote: > > On 29/4/21 2:31 am, Vijay Kumar Banerjee wrote: > > On Wed, Apr 28, 2021 at 12:45 AM Chris Johns wrote: > >> > >> On 28/4/21 2:48 am, Vijay Kumar Banerjee wrote: > >>> I came across the tcpreplay tool and it looks like a nice tool for > >>> testing the > >>> network stacks. It can be used to capture network traffic and then play > >>> it back, > >>> this will help with testing the network packets from different network > >>> stacks. > >>> > >>> My proposal is to add the tcpreply as a host-side tool in rtems-tools and > >>> use it > >>> with the network interface where the network application is running. The > >>> only > >>> issue that I see with the whole idea is that the tcpreplay is GPLv3 > >>> licensed. > >>> Will that be compatible for rtems-tools? The github repository says that > >>> it's > >>> compatible with UNIX and Windows with cygwin. > >>> > >>> Source repository:https://github.com/appneta/tcpreplay > >>> <https://github.com/appneta/tcpreplay> > >>> > >>> Thoughts and suggestions are much appreciated. > >> > >> It is GPLv3 so it cannot be imported as source. It can be referenced as a > >> command if available for the host. > >> > > Ok. > > > >> I also suggest you investigate VDE with qemu. This is what I use to avoid > >> being > >> root. > >> > > VDE looks great, I haven't tried it before. Thanks for the suggestion! > > I'll try this out. > > No problem. Amar put me on to it years ago. I like it because I can run a few > qemu networked sessions and I do not need to be root to do this. My host set > up > is simple... > > From /etc/rc.conf: > > cloned_interfaces="bridge0 tap0 tap1 tap2" > autobridge_interfaces="bridge0" > ifconfig_bridge0="inet 10.10.5.2 netmask 255.255.255.0" > autobridge_bridge0="re0.3 tap0 tap1 tap2" > > $ cat vde-start > #! /bin/sh > # > # vdeterm /tmp/mgmt1 > # > sysctl net.link.tap.user_open=1 > sysctl net.link.tap.up_on_open=1 > chmod 660 /dev/tap0 > vde_switch -d -s /tmp/vde1 -M /tmp/mgmt1 -tap tap0 -m 660 --mgmtmode 660 > > Note, I internally run a bridge that VDE attaches to and all this is layer 2. > The bridge is connected to a VLAN my engineering network runs on. You have to > expect varying levels of complexity in user networks. > Thank you for the detailed configuration. It certainly looks nicer compared to running wireshark using root. > > Can write some rtems-test recipes with VDE to > > automate the run? will that be feasible/possible? > > This depends on the type of testing you are looking to perform and the type of > network architecture you are considering. My set up lets a qemu session see my > network. I am bridging across it via a single tap that is created when the OS > boots. I have attached some slides I put together last year on this topic. > The slides are interesting, thanks. > The challenge is keeping the network infrastructure needed to a minimum, a > simple configuration, support for hardware and simulation targets and agnostic > network support. > I would certainly need to try it out for some manual runs first and then I might start to look at how can we come up with a minimal configuration for the automated testing. > Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
