Re: Jetson Nano BSP
Hello, On 2023-02-23 06:15, Joel Sherrill wrote: On Wed, Feb 22, 2023, 9:26 PM Prakhar Agrawal mailto:prakhar.agrawal...@gmail.com>> wrote: Hello, Does the current RTEMS version support the Jetson nano board, if not, do you think It will be a good project for gsoc2023? something like porting RTEMS to Jetson nano or jetson AGX orin maybe? I'm torn whether this is a good project or not. It is quite ambitious but it appears that a fair amount of the boards horsepower is tied to binary blobs which likely won't work with RTEMS. One challenge is that much of the support will be GPL licensed which is unacceptable for RTEMS. That said, it may be feasible since freebsd appears to support it now. I have no idea what devices work under freebsd. But if you can boot freebsd on it and see what works, that would be great information. https://cgit.freebsd.org/src/commit/?id=e903478919602c90fdc202a8628b89eb7c3bc104 <https://cgit.freebsd.org/src/commit/?id=e903478919602c90fdc202a8628b89eb7c3bc104> The other side of this is how useful this will be either for RTEMS users. What would a hobbyist use it for? A production team? Is the board too old to be worth the effort for the limited audience? The Jetson seems to be a big familiy. The Nano is from 2019 and has some chip that is most likely based on a chip from 2015? The Orin Nano is from September 2022 with some CPU that I didn't find on a quick search. Otherwise, I fully agree with what Joel said: Do we have some audience for it? They are not really cheap so hobby use is unlikely. I haven't found any source where I could buy small numbers of blank chips. In my experience, that often means that the manufacturer targets products where they sell big numbers of chips (at least 6 digit numbers). For these it's usually cheaper if the manufacturer just assigns a field application engineer to you instead of writing good documentation. If the Jetson falls into that category, it's not an easy project. Honestly I'd rather see a new BSP for a decent RISC-V board. Decent and not too expensive RISC-V would be interesting, but I haven't found too much of these yet. Only expensive stuff like the Renesas RZ/Five evaluation board or ones that are not yet easily available like the Pine Ox64 that I mentioned in other GSoC discussions already. If you find a nice cheap RISC-V board, it would be a great project. Other commonly available and well documented non-RISC-V boards or simulator targets can be interesting projects too. Best regards Christian Looking forward to your response. I'm also curious to hear what others think. --joel Best Regards Prakhar ___ devel mailing list devel@rtems.org <mailto:devel@rtems.org> http://lists.rtems.org/mailman/listinfo/devel <http://lists.rtems.org/mailman/listinfo/devel> ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
Re: GitLab and BuildBot
Hello Chris, On 2023-02-09 23:26, Chris Johns wrote: On 9/2/2023 6:24 pm, Christian MAUDERER wrote: Hello Chris, On 2023-02-08 23:35, Chris Johns wrote: On 8/2/2023 8:04 pm, Christian MAUDERER wrote: On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. There have been relatively new tickets that changed the status from "needs-funding" to "funded" nearly without delay. That was a bit surprising for me. It seems that the tickets are still updated based on feedback so that is fine and it's great that someone funded them. It just would have been nice if there would have been some announcement for two or three days like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly like they are written now. If there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. Seems that I exaggerated too much. It's a tendency that I have sometimes as an attempt to be descriptive. I'm sorry if that I haven't been more careful in my choice of words. Thanks and I understand it is not a natural language for you. Of course, it's not relevant for the list whether it's paid or not and who is paying. It doesn't have to have any special form either. But announcements for changes to the devel list are not unusual in general. For bigger changes it's often done before the change. Sometimes vague but it's at least announced (Example: New build system [1], [2], ...). If someone wants to know more or objects the planned changes he can speak up in these mail threads and concerns can be discussed and in the worst case a change can be rejected entirely. For smaller changes everyone just sends patches to the list that are usually accepted and sometimes rejected if someone objects. For infrastructure changes, a patch review after it is done isn't possible. So these are more the big kind of changes that should be announced with at least a few days time for someone to object or discuss. Tickets are nice but they are not very visible. Clearly explaining what is happening is important and if that has not been done then I apologise. The planned work on rtems.org has been split along the lines of infrastructure and services. Infrastructure is stuff no one normally cares about except Amar and myself with oversight by Joel and Gedare. The list includes redundant Cisco firewall updates, base OS updates, movement of jails support, the mess of IPMI+Java+Windows, logs, certs and what ever else the tickets have. The infrastructure lets us provide the services we run. The services we have will run as they have for the last 9 years. The upgraded infrastructure will let add new services such as CI and that is part of the selection process you have kindly participated in. Thanks for the explanation. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already had something similar in the comments, so I didn't think that someone would object as long as it is an anonymous "Someone wants to fund ..." and not "Company X wants to fund ...". Understood. My comment was a reminder to everyone and not specifically you. This discussion is archived so making sure what we are talking about is clear is important. Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. Maintenance tasks that keep the systems running are fine without an announcement. These are a lot of great work that happens behind the scenes. The maintenance has been happening for nearly 9 years unfunded. A lot of organisations and individuals have created a lot of systems running RTEMS and serviced a lot of clients in that time accessing this system. Lets not lose si
Re: GitLab and BuildBot
Hello Chris, On 2023-02-08 23:35, Chris Johns wrote: On 8/2/2023 8:04 pm, Christian MAUDERER wrote: On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. I did not know that was happening. I am sorry if you think it is and if I gave you that impression. There have been relatively new tickets that changed the status from "needs-funding" to "funded" nearly without delay. That was a bit surprising for me. It seems that the tickets are still updated based on feedback so that is fine and it's great that someone funded them. It just would have been nice if there would have been some announcement for two or three days like "Someone wants to fund the tickets 1, 2 and that part of 4 exactly like they are written now. If there are big objections with the direction, please speak up now." I have never seen EB, your employer, make such an announcement about private commercial in confidence contracts in this way and I would never expect EB to do that so I think it is outrageous you think you can ask this here like this. The funding is a private commercial agreement Amar has and it is no different to the ones your employer makes. Any questions need to be directed to Amar directly but I suggest the questions should be along of the lines of what you can fund. Seems that I exaggerated too much. It's a tendency that I have sometimes as an attempt to be descriptive. I'm sorry if that I haven't been more careful in my choice of words. Of course, it's not relevant for the list whether it's paid or not and who is paying. It doesn't have to have any special form either. But announcements for changes to the devel list are not unusual in general. For bigger changes it's often done before the change. Sometimes vague but it's at least announced (Example: New build system [1], [2], ...). If someone wants to know more or objects the planned changes he can speak up in these mail threads and concerns can be discussed and in the worst case a change can be rejected entirely. For smaller changes everyone just sends patches to the list that are usually accepted and sometimes rejected if someone objects. For infrastructure changes, a patch review after it is done isn't possible. So these are more the big kind of changes that should be announced with at least a few days time for someone to object or discuss. Tickets are nice but they are not very visible. This list is open and public for the project and its community and I will not tolerant any commercial activity of any type. Sorry, shouldn't have mentioned "Someone wants to fund ...". The tickets already had something similar in the comments, so I didn't think that someone would object as long as it is an anonymous "Someone wants to fund ..." and not "Company X wants to fund ...". Regarding the tickets, there are many cases over the years of those providing services performing services internally, raising tickets and committing changes. I see no issue here and I am fine with that continuing to happen. Finally, my understanding of the funded tickets is most of the work is to rebuild the servers to be current and capable of running modern CI systems, what ever that ends up being. Maintenance tasks that keep the systems running are fine without an announcement. These are a lot of great work that happens behind the scenes. But these tasks don't change how a user can access the system. It's great if someone decides to make that work visible too so that everyone can at least say a "thank you", but it's not necessary. For tasks that change something fundamental, some public review time would be nice at least a few days before the work starts. Like said above: I would see that similar to review time for every patch that is more or less a suggestion to change something. I haven't seen that announcement and review time for the tickets that are already funded. Maybe I missed it and if that is the case it's fully my fault and I'm sorry that I even started the discussion. On the other hand all currently funded tickets fall into the category "necessary maintenance task" so I clearly overreacted to even mention it. Regarding the commercial aspect: Of course an announcement doesn't have to happen before a contract is closed - that is something between the two companies or individuals that close the contract. But like you said multiple times yourself: It's not a contract that the RTEMS project closes but one between two unrelated legal entities. So it's still possible that a community members might object and in the worst case block the change. Just to make that clear again: Except
Re: GitLab and BuildBot
On 2023-02-07 23:37, Chris Johns wrote: On 7/2/2023 9:31 pm, Christian MAUDERER wrote: On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. It is exciting to see this happening. It will benefit the project and all who give their time. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? I suggest a ticket to handle authentication. If you create a ticket please indicate it is unfunded. If this is handled else where and in another ticket this one can be closed with a suitable reason. https://devel.rtems.org/ticket/4840 Thanks. The addition of these authentication methods can be done when someone funds the work. If a person or organisation thinks it is important please reach out to Amar directly. Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? There are details that will need to be worked out. Deployment of tools for building in a CI flow is important. How complex and automated this will be will depends on the funding provided. At this point in time the push is to get a basic framework up that allows us to handle simple merge requests. The approach is more organic in nature so funding can be targeted at the most important foundation pieces. Further funding can build on that base. Before we get to Gitlab and CI we need to rebase the servers and software on them. This part of the effort is funded and under way. Amar is updating the tickets with the progress. Maybe my question hasn't been clear enough. Of course part of it depends on what is implemented. But every selected system also adds limitations. At the moment BuildBot is the suggested system in the tickets. It is a well known service and has a lot of usefull features for us that certainly make it a good choice. But I never really worked with it, so I basically wanted to know what I have to expect. Some systems like (I think it was) jenkins.io can be configured to behave quite different depending on how you use it. You can either configure it via a static configuration that is put somewhere where only admins can access it. But you can also configure it in a way that build jobs are defined by yaml files in the repository similar to popular services like GitHub, GitLab or Travis. Basically what I wanted to know is: What is possible / usual with BuildBot and which of the possible solutions do we want to use? A developer with a gitlab account will be encouraged to move their personal repo to their gitlab account and doing that allows them to use the gitlab CI tools. Gitlab will be running on FreeBSD and in a jail so any dependent services a developer needs will need to be requested via a ticket. I hope you appreciate there are limit here related to resources and the hardened nature of the environment. Of course there are limits. That's OK. Do we configure BuildBot statically and every change will be done only if someone pays for it? The main CI build flows will be controlled and changed via a ticket. We need to QA control that process to ensure the patches merged are suitable. I have no idea yet how this will look and work but it will need to allow the project to make updates. Wether this is widely available on the first pass or pass ten of the work that needs to be done I cannot say
Re: [PATCH 1] Changed Hello World
Hello Prakhar,
that looks suspiciously like a HTML mail (or rather a mixed mode mail).
How did you send that patch? Usually it's best to use git send-email to
send patches to the list so that no mail client messes up formatting
which helps with applying patches again.
Best regards
Christian
On 2023-02-07 09:17, Prakhar Agrawal wrote:
From: Prakhar <mailto:prakhar.agrawal...@gmail.com>>
Date: Tue, 7 Feb 2023 13:43:09 +0530
Subject: [PATCH 4/4] updated hello.c
---
hello.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/hello.c b/hello.c
index 72d1dd4..a3c40ae 100644
--- a/hello.c
+++ b/hello.c
@@ -9,6 +9,6 @@ rtems_task Init(
rtems_task_argument ignored
)
{
- printf( "\nHello World\n" );
+ printf( "\nHello RTEMS from Prakhar!\n" );
exit( 0 );
}
--
2.25.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
----
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
Re: GitLab and BuildBot
On 2023-02-07 07:03, Chris Johns wrote: On 30/1/2023 10:12 pm, Christian MAUDERER wrote: Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. It is exciting to see this happening. It will benefit the project and all who give their time. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? I suggest a ticket to handle authentication. If you create a ticket please indicate it is unfunded. If this is handled else where and in another ticket this one can be closed with a suitable reason. https://devel.rtems.org/ticket/4840 The addition of these authentication methods can be done when someone funds the work. If a person or organisation thinks it is important please reach out to Amar directly. Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? There are details that will need to be worked out. Deployment of tools for building in a CI flow is important. How complex and automated this will be will depends on the funding provided. At this point in time the push is to get a basic framework up that allows us to handle simple merge requests. The approach is more organic in nature so funding can be targeted at the most important foundation pieces. Further funding can build on that base. Before we get to Gitlab and CI we need to rebase the servers and software on them. This part of the effort is funded and under way. Amar is updating the tickets with the progress. Maybe my question hasn't been clear enough. Of course part of it depends on what is implemented. But every selected system also adds limitations. At the moment BuildBot is the suggested system in the tickets. It is a well known service and has a lot of usefull features for us that certainly make it a good choice. But I never really worked with it, so I basically wanted to know what I have to expect. Some systems like (I think it was) jenkins.io can be configured to behave quite different depending on how you use it. You can either configure it via a static configuration that is put somewhere where only admins can access it. But you can also configure it in a way that build jobs are defined by yaml files in the repository similar to popular services like GitHub, GitLab or Travis. Basically what I wanted to know is: What is possible / usual with BuildBot and which of the possible solutions do we want to use? Do we configure BuildBot statically and every change will be done only if someone pays for it? Will there be a repo with config files where everyone can suggest and help but only one or two admins can accept changes if they have time? Or will every repo contain a config yaml (or similar format) and every maintainer can accept a change to that? Or is the currently discussed solution something completely different? That shouldn't be a pure decision by the one who pays for the work but one that is (in the optimal case) discussed and specified in the tickets. That way everyone in the community has at least a chance to have some influence on the system that he will have to use later. Best regards Christian The hope is gitlab admin activities can be shared. Amar and I have briefly discussed this but nothing has been decided. We need a gitleb instance before this becomes something we need to handle. Chris -- embedded brains
Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals
Hello Chris, On 2023-02-07 05:42, Chris Johns wrote: On 6/2/2023 7:07 pm, Christian MAUDERER wrote: Hello Chris, thanks for your feedback on the patch. No problem :) On 2023-02-06 05:16, Chris Johns wrote: On 3/2/2023 6:31 pm, Christian Mauderer wrote: This patch tries to make the most important goals of LibBSD development more clear based on the results of the discussion on the mailing list: https://lists.rtems.org/pipermail/devel/2023-January/074164.html --- CONTRIBUTING.rst | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 0b6fc7a0..31561f6a 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the FreeBSD source are permitted, and some other topics. For building the library, see the `README `_. -Goals of the LibBSD activity are - -* provide functionality from FreeBSD to RTEMS, -* ease updating to future FreeBSD versions, -* ease tracking changes in FreeBSD code, -* minimize manual changes in FreeBSD code. - -We will work to push our changes upstream to the FreeBSD Project and minimize -changes required at each update point. +Every change to LibBSD has to consider the following points in groups of +descending priority: + +#. Real-time Impacts + Maintainability Loss + * LibBSD itself doesn't make any real time claims because it is basically + FreeBSD and they don't make any real time claims either. But all + development in LibBSD must make sure that the real time ability of the + RTEMS core system or the application is not affected. + * It's utterly important that LibBSD is simple to maintain. One of the most + important points for that is that upgrades to newer FreeBSD versions have + to be easy. Correct and it is important we adopt and use what FreeBSD provides rather than adding extra complexity. I wrote about this in the FreeBSD journal years ago. The bespoke handing of fd and file objects is something I consider an unneeded complexity for specific system related reasons. We need NFSv4 and that uses VFS and that in turn uses the FreeBSD fd and file objects. I'm trying to find out what rules are agreed by most of us. I feel we need simplicity. I was surprised by the number of undefined rules my changes tripped over and to be honest I still have no idea what they are, why they exist and who made them? It's of course OK to bring examples. But I think we should try to evaluate the currently discussed patch set based on the results together with as many of the other maintainers as possible as soon as we agree on the rules that we want to use to evaluate them. The rules for the changes I made are simple. It is transparency of the FreeBSD code. The file descriptors are an example where I know that Sebastian and you will argument that their solution is the right one. He may but his view is only one view and fixed and I am sorry but the forceful and sometimes short nature of his responses has not helped his cause. Then let's hope that my tendency to write long mails can help to bring the discussion a bit forward ;-) I found the port of NFSv4 easy until I hit the fd/file parts. The complexity then grew and as I attempted to sort one piece out I hit another location and in the end I had little confidence about the changes I had made. Each change started to appear like a slight variation of the same thing for each descriptor type. In the end I decided the size of changes had grown to big so I decided to switch direction and bring across the FreeBSD code as close as possible and to move libbsd in the that direction because the closer we had VFS to FreeBSD the simpler the testing of complex pieces like the vnode cache and lookup would be. As far as I understood Sebastian, the fd/file parts add quite a bit of code which has to be maintained too and which duplicates part of RTEMS core infrastructure. Is it really simpler to understand more code and an extra layer? Maybe that also depends on the background of the person who looks at the code. If someone reads that code first time: Let's assume he or she has worked with FreeBSD sources before. In that case it might is simpler to understand the code if the FreeBSD file descriptors are in the sources. Let's assume the other case: He or she has worked only with small real time systems. In that case it might is quite odd that there are two code parts that more or less do the same and handle files. It is a trade-off whether it's simpler to cut above the fd/file parts or below them. And most likely it's one that is very subjective. It is important to note we need code the project can maintain and as a result of my deep dive I now question who can maintain the fd/file support as it was? You could ask the same question: Who (except for you) can maintain fd/file support as it is now on 6
Re: libbsd development policy clarification needed?
On 2023-02-06 16:06, Gedare Bloom wrote: On Mon, Feb 6, 2023 at 2:26 AM Christian MAUDERER wrote: On 2023-02-06 10:02, Christian MAUDERER wrote: On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history
Re: libbsd development policy clarification needed?
On 2023-02-06 10:02, Christian MAUDERER wrote: On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly ol
Re: libbsd development policy clarification needed?
On 2023-02-05 11:38, Christian Mauderer wrote: Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer com
Re: [PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals
Hello Chris, thanks for your feedback on the patch. On 2023-02-06 05:16, Chris Johns wrote: On 3/2/2023 6:31 pm, Christian Mauderer wrote: This patch tries to make the most important goals of LibBSD development more clear based on the results of the discussion on the mailing list: https://lists.rtems.org/pipermail/devel/2023-January/074164.html --- CONTRIBUTING.rst | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 0b6fc7a0..31561f6a 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the FreeBSD source are permitted, and some other topics. For building the library, see the `README `_. -Goals of the LibBSD activity are - -* provide functionality from FreeBSD to RTEMS, -* ease updating to future FreeBSD versions, -* ease tracking changes in FreeBSD code, -* minimize manual changes in FreeBSD code. - -We will work to push our changes upstream to the FreeBSD Project and minimize -changes required at each update point. +Every change to LibBSD has to consider the following points in groups of +descending priority: + +#. Real-time Impacts + Maintainability Loss + * LibBSD itself doesn't make any real time claims because it is basically + FreeBSD and they don't make any real time claims either. But all + development in LibBSD must make sure that the real time ability of the + RTEMS core system or the application is not affected. + * It's utterly important that LibBSD is simple to maintain. One of the most + important points for that is that upgrades to newer FreeBSD versions have + to be easy. Correct and it is important we adopt and use what FreeBSD provides rather than adding extra complexity. I wrote about this in the FreeBSD journal years ago. The bespoke handing of fd and file objects is something I consider an unneeded complexity for specific system related reasons. We need NFSv4 and that uses VFS and that in turn uses the FreeBSD fd and file objects. I'm trying to find out what rules are agreed by most of us. It's of course OK to bring examples. But I think we should try to evaluate the currently discussed patch set based on the results together with as many of the other maintainers as possible as soon as we agree on the rules that we want to use to evaluate them. The file descriptors are an example where I know that Sebastian and you will argument that their solution is the right one. I think that can only be decided with the help of some more people. Source transparency is what matters and as a test of what is acceptable it must be preferred between competing implementations. +#. Transparency Loss + Modularity Loss + Code/RAM Size Increase + * LibBSD code should be easy to read and easy to debug. Changes should be + integrated in a way that are easy to understand. Of course that's a + subjective goal. As a general rule: If it adds lot's of extra code or even + more layers than already exist in FreeBSD, it's harder to understand. + * There are a number of methods used in LibBSD to make it modular. If you + add new functionality, use one of the existing methods to allow enabling or + disabling your module. For example make sure that the linker can remove + unused modules. If that doesn't work for your feature, try to use the + buildsets to allow to switch a module on or off. + * A lot of different hardware uses LibBSD as network or USB stack or maybe in + the future even only for other subsystems. Some of the targets have + hundreds of megabytes memory. Others can only have a few megabytes (like + the ATSAMV71). Make sure that changes don't increase the RAM / Flash size + of the default build so that it can't be used on the small targets. This is not realistic or achievable and I find confusing the reasons it is being pushed over and over. I would have not have agreed to this being added before now and nothing has changed. The central reason for rejecting this statement is a change in FreeBSD may add a few meg of memory to the footprint and this type of statement would conflict with that addition and that in turn would conflict with the need for transparency of source. And as stated before transparency must be preferred. Maintainability is the point that has the highest priority in my suggestion. I grouped transparency, modularity and size like Gedare suggested because there might be cases where we want to prefer one over the other. Transparency is also a bit difficult and often subjective. I defined it here as 'easy to read' and 'easy to debug'. These two alone can conflict each other. For example more layers can sometimes make something simpler to read because it is nicely abstracted, but it can make it horrible hard to debug a problem because you have to step through all
Re: libbsd development policy clarification needed?
Am 04.02.23 um 01:25 schrieb Gedare Bloom: On Fri, Feb 3, 2023 at 3:29 PM Christian Mauderer wrote: Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : On Fri, Feb 3, 2023 at 12:52 PM wrote: Hello Gedare, Am 03.02.23 um 19:51 schrieb Gedare Bloom: On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER wrote: Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. I have been investigating this problem in the background, and I have some findings and some questions. First, I have found that there is a most-common ancestor between master and 6-freebsd-12 at commit https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 This is at least promising that the discrepancy between the branches can be resolved. The proposed pending patch set to "fix" the NFS issue does not fix the underlying problem. Instead, it introduces further divergence between the branches. I would instead suggest that we should resolve to fix the underlying problem. I can see two paths forward. 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal since what I understand is some users have projects based on 6-freebsd-12 and would like an upgrade path. (I guess there is also the option to abandon master, which also makes little sense.) A variant for this would be to introduce a 6-freebsd-13 that is based on the master branch as soon as we have one. That would allow a longer maintenance because FreeBSD 12 reaches it's EoL December 2023. 2. Pull commits from 6-freebsd-12 into master to make sure master is the development head. in the future, reject patches that only go toward release branches. This has its own problems too. It can realistically only be done in three ways: Please note that Sebastian mentioned that the file descriptors broke the NTP support (at least I think it was NTP; possible that it was another submodule). So picking the current version of the patches into the master without adding fixes makes the master unusable for some cases. Fixing the problems after making the branches the same will be better for the long-term, if we can find a path to do it. 2a: Rebase master and cherry-pick commits from 6-freebsd-12 and master back into master. This rewrites the history of master, and unfortunately will cause the head of 5-freebsd-12 and the tags for rtems-5 to no longer exist on the master branch. They will still exist in the '5' branch. The advantage is in the end there will be a linear history of development on master that reflects the timeline of actual development that spanned both branches. Theoretically, this should make it easier to git-bisect. 2b: Cherry-pick commits from 6-freebsd-12 to master and fix conflicts. This puts all the missing commits from 6-freebsd-12 on to the current head of master. I don't know how messy this would be. It ends up making the history of master convoluted to understand, with fairly old commits from 2018 being placed on top of newer commits from 2020s. 2c: Merge 6-freebsd-12 into master and fixup conflicts in the merge commit. This is
Re: libbsd development policy clarification needed?
Am 3. Februar 2023 22:52:48 MEZ schrieb Gedare Bloom : >On Fri, Feb 3, 2023 at 2:39 PM Christian Mauderer wrote: >> >> >> >> Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : >> >On Fri, Feb 3, 2023 at 12:52 PM wrote: >> >> >> >> Hello Gedare, >> >> >> >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: >> >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER >> >> > wrote: >> >> >> >> >> >> Hello Karel, >> >> >> >> >> >> On 2023-02-02 12:43, Karel Gardas wrote: >> >> >>> >> >> >>> Guys, >> >> >>> >> >> >>> recently I needed to work with RTEMS/NFS. As this is provided by >> >> >>> libbsd >> >> >>> I took this and following two sentences below from master branch >> >> >>> description provided in README I took as granted that master does have >> >> >>> all the features which are currently available and provided by the >> >> >>> project: >> >> >>> >> >> >>> "This branch must be used for libbsd development. Back ports to the >> >> >>> 6-freebsd-12 are allowed." >> >> >>> >> >> >>> I was surprised to be proven wrong then by Fabrizio here: >> >> >>> https://devel.rtems.org/ticket/4723 >> >> >>> >> >> >>> and by later investigation which shows that 6-freebsd-12 branch >> >> >>> accumulated NFS work by Chris done in 2021 which is not presented on >> >> >>> master. I've investigated just NFS as this was my focus here. >> >> >>> >> >> >>> So if 6-freebsd-12 became development branch of some sort, then it >> >> >>> would >> >> >>> be great to have that clarified in the project README file to prevent >> >> >>> users confusion? Or if the policy is still the same, then perhaps some >> >> >>> branch sync is needed here? >> >> >> >> >> >> That currently is an open issue. Basically there is a pending patch set >> >> >> that should fix that since several months. But there is a disagreement >> >> >> about some of the changes in that patch set (and about the patches >> >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. >> >> >> >> >> >> If you want to know some more about the problematic points, I recommend >> >> >> reading this (long) thread: >> >> >> >> >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html >> >> >> >> >> >> The statement that development has to happen on the master branch is >> >> >> still true. The master is intended to track the FreeBSD upstream >> >> >> development. Only changes on that branch are guaranteed to live through >> >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, >> >> >> that there are some patches on the 6-freebsd-12 branch only. On the >> >> >> long >> >> >> term, that issue has to be resolved. >> >> >> >> >> > >> >> > I have been investigating this problem in the background, and I have >> >> > some findings and some questions. First, I have found that there is a >> >> > most-common ancestor between master and 6-freebsd-12 at commit >> >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 >> >> > This is at least promising that the discrepancy between the branches >> >> > can be resolved. >> >> > >> >> > The proposed pending patch set to "fix" the NFS issue does not fix the >> >> > underlying problem. Instead, it introduces further divergence between >> >> > the branches. I would instead suggest that we should resolve to fix >> >> > the underlying problem. I can see two paths forward. >> >> > >> >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal >> >> > since what I understand is some users have projects based on >> >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also >> >> > the option to abandon master, w
Re: libbsd development policy clarification needed?
Am 3. Februar 2023 22:12:06 MEZ schrieb Gedare Bloom : >On Fri, Feb 3, 2023 at 12:52 PM wrote: >> >> Hello Gedare, >> >> Am 03.02.23 um 19:51 schrieb Gedare Bloom: >> > On Thu, Feb 2, 2023 at 11:24 PM Christian MAUDERER >> > wrote: >> >> >> >> Hello Karel, >> >> >> >> On 2023-02-02 12:43, Karel Gardas wrote: >> >>> >> >>> Guys, >> >>> >> >>> recently I needed to work with RTEMS/NFS. As this is provided by libbsd >> >>> I took this and following two sentences below from master branch >> >>> description provided in README I took as granted that master does have >> >>> all the features which are currently available and provided by the >> >>> project: >> >>> >> >>> "This branch must be used for libbsd development. Back ports to the >> >>> 6-freebsd-12 are allowed." >> >>> >> >>> I was surprised to be proven wrong then by Fabrizio here: >> >>> https://devel.rtems.org/ticket/4723 >> >>> >> >>> and by later investigation which shows that 6-freebsd-12 branch >> >>> accumulated NFS work by Chris done in 2021 which is not presented on >> >>> master. I've investigated just NFS as this was my focus here. >> >>> >> >>> So if 6-freebsd-12 became development branch of some sort, then it would >> >>> be great to have that clarified in the project README file to prevent >> >>> users confusion? Or if the policy is still the same, then perhaps some >> >>> branch sync is needed here? >> >> >> >> That currently is an open issue. Basically there is a pending patch set >> >> that should fix that since several months. But there is a disagreement >> >> about some of the changes in that patch set (and about the patches >> >> checked in to 6-freebsd-12). Therefore, it still hasn't been merged. >> >> >> >> If you want to know some more about the problematic points, I recommend >> >> reading this (long) thread: >> >> >> >> https://lists.rtems.org/pipermail/devel/2023-January/074164.html >> >> >> >> The statement that development has to happen on the master branch is >> >> still true. The master is intended to track the FreeBSD upstream >> >> development. Only changes on that branch are guaranteed to live through >> >> an upgrade to a newer base version of FreeBSD. It's very unfortunate, >> >> that there are some patches on the 6-freebsd-12 branch only. On the long >> >> term, that issue has to be resolved. >> >> >> > >> > I have been investigating this problem in the background, and I have >> > some findings and some questions. First, I have found that there is a >> > most-common ancestor between master and 6-freebsd-12 at commit >> > https://git.rtems.org/rtems-libbsd/commit/?h=6-freebsd-12=2ce13cf6dc73855f28bc7edbbc64dc4b482a4976 >> > This is at least promising that the discrepancy between the branches >> > can be resolved. >> > >> > The proposed pending patch set to "fix" the NFS issue does not fix the >> > underlying problem. Instead, it introduces further divergence between >> > the branches. I would instead suggest that we should resolve to fix >> > the underlying problem. I can see two paths forward. >> > >> > 1. Abandon 6-freebsd-12 after releasing 6. This is probably not ideal >> > since what I understand is some users have projects based on >> > 6-freebsd-12 and would like an upgrade path. (I guess there is also >> > the option to abandon master, which also makes little sense.) >> >> A variant for this would be to introduce a 6-freebsd-13 that is based on >> the master branch as soon as we have one. That would allow a longer >> maintenance because FreeBSD 12 reaches it's EoL December 2023. >> >> > >> > 2. Pull commits from 6-freebsd-12 into master to make sure master is >> > the development head. in the future, reject patches that only go >> > toward release branches. This has its own problems too. It can >> > realistically only be done in three ways: >> >> Please note that Sebastian mentioned that the file descriptors broke the >> NTP support (at least I think it was NTP; possible that it was another >> submodule). So picking the current version of the patches into the >> master without adding fixe
[PATCH rtems-libbsd] CONTRIBUTING: Sharpen priority development goals
This patch tries to make the most important goals of LibBSD development more clear based on the results of the discussion on the mailing list: https://lists.rtems.org/pipermail/devel/2023-January/074164.html --- CONTRIBUTING.rst | 39 ++- 1 file changed, 30 insertions(+), 9 deletions(-) diff --git a/CONTRIBUTING.rst b/CONTRIBUTING.rst index 0b6fc7a0..31561f6a 100644 --- a/CONTRIBUTING.rst +++ b/CONTRIBUTING.rst @@ -21,15 +21,36 @@ RTEMS specific support files, general guidelines on what modifications to the FreeBSD source are permitted, and some other topics. For building the library, see the `README `_. -Goals of the LibBSD activity are - -* provide functionality from FreeBSD to RTEMS, -* ease updating to future FreeBSD versions, -* ease tracking changes in FreeBSD code, -* minimize manual changes in FreeBSD code. - -We will work to push our changes upstream to the FreeBSD Project and minimize -changes required at each update point. +Every change to LibBSD has to consider the following points in groups of +descending priority: + +#. Real-time Impacts + Maintainability Loss + * LibBSD itself doesn't make any real time claims because it is basically + FreeBSD and they don't make any real time claims either. But all + development in LibBSD must make sure that the real time ability of the + RTEMS core system or the application is not affected. + * It's utterly important that LibBSD is simple to maintain. One of the most + important points for that is that upgrades to newer FreeBSD versions have + to be easy. +#. Transparency Loss + Modularity Loss + Code/RAM Size Increase + * LibBSD code should be easy to read and easy to debug. Changes should be + integrated in a way that are easy to understand. Of course that's a + subjective goal. As a general rule: If it adds lot's of extra code or even + more layers than already exist in FreeBSD, it's harder to understand. + * There are a number of methods used in LibBSD to make it modular. If you + add new functionality, use one of the existing methods to allow enabling or + disabling your module. For example make sure that the linker can remove + unused modules. If that doesn't work for your feature, try to use the + buildsets to allow to switch a module on or off. + * A lot of different hardware uses LibBSD as network or USB stack or maybe in + the future even only for other subsystems. Some of the targets have + hundreds of megabytes memory. Others can only have a few megabytes (like + the ATSAMV71). Make sure that changes don't increase the RAM / Flash size + of the default build so that it can't be used on the small targets. +#. Performance Loss + * There are applications, that require (for example) a high network + throughput or a fast storage access. Make sure to take that into account + if adding changes. What is in the Git Repository = -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: libbsd development policy clarification needed?
Hello Karel, On 2023-02-02 12:43, Karel Gardas wrote: Guys, recently I needed to work with RTEMS/NFS. As this is provided by libbsd I took this and following two sentences below from master branch description provided in README I took as granted that master does have all the features which are currently available and provided by the project: "This branch must be used for libbsd development. Back ports to the 6-freebsd-12 are allowed." I was surprised to be proven wrong then by Fabrizio here: https://devel.rtems.org/ticket/4723 and by later investigation which shows that 6-freebsd-12 branch accumulated NFS work by Chris done in 2021 which is not presented on master. I've investigated just NFS as this was my focus here. So if 6-freebsd-12 became development branch of some sort, then it would be great to have that clarified in the project README file to prevent users confusion? Or if the policy is still the same, then perhaps some branch sync is needed here? That currently is an open issue. Basically there is a pending patch set that should fix that since several months. But there is a disagreement about some of the changes in that patch set (and about the patches checked in to 6-freebsd-12). Therefore, it still hasn't been merged. If you want to know some more about the problematic points, I recommend reading this (long) thread: https://lists.rtems.org/pipermail/devel/2023-January/074164.html The statement that development has to happen on the master branch is still true. The master is intended to track the FreeBSD upstream development. Only changes on that branch are guaranteed to live through an upgrade to a newer base version of FreeBSD. It's very unfortunate, that there are some patches on the 6-freebsd-12 branch only. On the long term, that issue has to be resolved. Best regards Christian I'm fine with either way, as a user I just need clear not confusing project message... Thanks! Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
GitLab and BuildBot
Hello, recently the following tickets were added (beneath a few more related ones): https://devel.rtems.org/ticket/4790 - Setup Gitlab instance https://devel.rtems.org/ticket/4791 - Update BuildBot It's great that a patch review system and a CI/CD that builds every patch for RTEMS starts to get within reach. Thanks a lot to all involved in that for the efforts. I reviewed earlier discussions related to CI/CD. From my point of view there are mainly two points that are missing in the tickets: First: From my point of view, we should make it simple for new users to register. Adding authentication using well-known services can help with that. GitLab supports (for example): - GitHub: https://docs.gitlab.com/ee/integration/github.html - GitLab.com: https://docs.gitlab.com/ee/integration/gitlab.html - Google: https://docs.gitlab.com/ee/integration/google.html - ... I think it would be good to select the most common ones (at least the three mentioned above) and add them as a goal to the ticket or a new one. What do you think? Second: It's still a bit unclear for me how the CI/CD with BuildBot will work. Will it be possible for anyone to help improve the CI/CD? An example to make it clear what I want to know: Let's assume an unprivileged developer has a patch set that allows building device tree files using the RTEMS build system, but the patches require a new tool like dtc. Let's further assume that the idea has been discussed and everyone agrees that it is a good idea (currently not yet the case for dtc). Problem is: The patches trigger a CI error because the new tool is missing and therefore can't be merged yet. How can the developer suggest a fix so that the patches can be accepted faster without having to wait for one specific maintainer to have enough time for adapting the CI config? 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 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-26 10:26, Christian MAUDERER wrote: On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms lose when going wi
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 19:10, Peter Dufault wrote: On Jan 25, 2023, at 10:55 , Gedare Bloom wrote: On Wed, Jan 25, 2023 at 2:25 AM Christian MAUDERER wrote: On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- Thanks for taking this on. Instead of a strict priority for the goals, we might consider a limited set of different priorities that require judgment to make good trade-offs. In this case, I would suggest the following as somewhat equivalent goals, and the sets in priority order: 1. Real-time Impacts + Maintainability Loss 2. Transparency Loss + Modularity Loss + Code/RAM Size Increase 3. Performance Loss I wrote each goal now as a "minimize" objective. I think it is not possible to establish strict priorities on these objectives. Good engineering requires understanding and making good tradeoffs. I believe that #1 addresses the highest requirements we place on RTEMS and the libbsd philosophy. #2 leaves us with the burden of discussing and debating when tradeoffs are made. It may be better in some cases to increase code size by increasing modularity, but in other cases it may be better to reduce transparency to reduce code size. Gedare I'm presenting my concerns without doing appropriate research. This ties in to other needed RTEMS specifications, in particular, the specification of whsy light-weight IP can support, and if it is possible to have a project to tie "libbsd" drivers into the LWIP infrastructure (*I* don't know if that's possible). Yes, I want my cake, and eat it too. "It would be great" if it is clear what small memory platforms lose when going with "LWIP" vs "libbsd", and how e
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 10:05, Sebastian Huber wrote: On 25.01.23 10:01, Christian MAUDERER wrote: On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? Lets say you are a user of libbsd version X. Then you want to update to version X + 1. Version X + 1 no longer works on your system, because libbsd needs more RAM than you have. Would you really give this user an answer like this: Sorry, maintainability and transparency is more important for us, so please stick to version X. Regarding code / RAM size versus maintainability: Maintainability does also include the upgrade process to newer base versions of FreeBSD. So if it's more important that code size doesn't increase compared to how easy libbsd is to maintain, that can make upgrades to newer FreeBSD versions _very_ difficult. I don't think that would be a good trade. Code size versus transparency (how easy it is for someone new to start development and how easy it is to debug through the code) is a bit more opinion based. The current order is from what I have understood in the discussion. I don't have a problem to re-order these. Note: I'm OK with most orders as long as most of the maintainers can agree on one. -- 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
On 2023-01-25 09:59, Sebastian Huber wrote: On 25.01.23 09:52, Christian MAUDERER wrote: OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? I would not give the minimum RAM size such a low priority. libbsd used to work on systems with 16MiB. If you add new things which require additional 4MiB even if you don't use the stuff, then you simply kick out systems which used to work with libbsd. So no lower than modularity. Should it be higher than transparency or maintainability? From the earlier comments I don't expect that it should be higher than (core) real time capability. What would be your preferred order? -- 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
Re: Prioritizing and documenting libbsd development goals (was: libbsd updates)
OK. Updated list based on Thomas and Sebastians feedback: From highest to lowest priority: - Real time capabilities: No hard real time requirements for libbsd core, but we have to make sure that it doesn't have a (relevant) negative impact on other subsystems. - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Performance: Whether libbsd performs well enough in the typical use cases. Any more suggestions for the order? Like I said, I would like to integrate that to the libbsd documentation as goals for that subsystem that can be used to evaluate different approaches for implementing something. Would be good to have some more feedback from others too. For example: I prioritized maintainability over transparency. That means that we might choose a solution that's simpler to maintain but makes it harder to integrate new modules. Is that OK? Similar the order of modularity and code / RAM size can be an issue: Most of the time these should go well together. But it's quite possible that some nice modular configuration options need extra code compared to less nice methods. From my point of view we target embedded systems where code and RAM size is more important. But I'm not sure that this is the focus for everyone else too? Best regards Christian On 2023-01-23 16:43, Sebastian Huber wrote: On 23.01.23 16:39, Thomas DOERFLER wrote: since we are maintaining an RTOS: IMHO Real time capabilities would need a higher level, even above code/RAM sizes. Meaining that the libbsd functionality should not have a (significant) negative impact on RTEMS tasks NOT using libbsd. There is actually a good example for this area in libbsd, the Epoch Based Reclamation. It has an RTEMS-specific implementation which required to add new features to the low level thread dispatching and scheduling implementation. In particular, the support for thread pinning. -- 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
Prioritizing and documenting libbsd development goals (was: libbsd updates)
Hello, like suggested earlier in the original discussion I would suggest to prioritize our development goals for libbsd and later evaluate the two problems discussed in the thread based on this. Let's first agree on development goals (that also can be added to the libbsd documentation). From the thread and responses, I currently have collected the following goals / priorities. I replaced my original extensibility and debuggability with Joels transparency because it's a good summary term for these two points. From highest to lowest priority: - Maintainability: How easy is it for the people doing the main maintenance tasks to do that work. - Transparency: How easy it is to understand the code? Relevant for extending and debugging. - Code and RAM sizes (or other hardware requirements): Whether we meet the minimum hardware requirements. - Modularity: How well and easy the system can be adapted to target applications. Have only few official ways to enable / disable modules in the subsystem. - Real time capabilities: No hard real time requirements for libbsd core but we have to make sure that it doesn't have a negative impact on other subsystems. - Performance: Whether libbsd performes well enough in the typical use cases. That means (for example): If it makes the system more maintainable, the performance isn't that important. If it reduces the size, we can trade off some performance or real time capabilities. Would you prioritize different? Did I miss some additional points from the discussion? Best regards Christian On 2023-01-20 08:32, Christian MAUDERER wrote: Hello, recently an internal discussion about updates in the libbsd started. All who participated in the discussion agreed that we should move the discussion to a public one. Below you can find the mail thread. It's oldest mail first. Mails are split with lines of = signs. I removed some duplicated mail text in case there were no inline comments. The date/time of the mails are in my current locale which is UTC+1. Best regards Christian = On 2023-01-03 16:52, Thomas DOERFLER wrote: Hello, first of all I wish you all a healthy, happy and successful new year. Unfortunately I already have to re-raise an issue: One of our customers has asked us about the RTEMS libbsd update policy. Since we still use a rather old libbsd version, it contains "OpenSSL 1.1.1d-freebsd 10 Sep 2019", there are many openSSL fixes missing when using RTEMS, and this most likely is true for other parts of libbsd. IMHO we should find a way to overcome the current libbsd update blocking points and try to stay close to the FreeBSD code (maybe in a 1-3 month interval). AFAIK the big blocking point are the different views around changes of the file descriptor handling between RTEMS and BSD (this may be a bit off the real topic, I am not yet into the details). In the next week I would like to get things rolling to see the pros and cons of both possible implementations and I would be happy if those closely involved would support this. Apart from the current blocking point, can we agree that staying close the the FreeBSD code (with a 1-3 month update/sync interval) would be desirable? Kind regards to you all, Thomas. = On 2023-01-12 01:24, Gedare Bloom wrote: Hi Thomas, I think the goal you have stated is laudable and fits with the initial design goals of libbsd. I will take a closer look at this topic and report back soon, I hope. I have remained (purposefully) ignorant about libbsd evolution over time, but I guess it is time for me to learn a bit more and catch up. From what I have understood about the current blocking issue, it has to do with the changes that were made to use FreeBSD File Descriptors and the VFS. However, one of the main problems that was noted actually appears to be just related to the size increase caused by the syscall glue implemented in a single .c file. So, I will plan to start my libbsd learning adventure by trying to split that .c file apart into separate build components to see how/if that alleviates the linked image size. If successful, that should get us closer. I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. It would also be helpful to decide if we want to clarify any requirements for libbsd maintenance. So, for example, the ability to keep it updated on a rolling basis would require good automation and validation that changes/updates remain usable. It would appear that there are some minimum resource requirements that some users of libbsd would like to remain under if possible. To ensure that would require establishing what platform(s) have resource requirements for using libbsd, and adding configurations/testing to check for when those resources are exceeded by an update. Because it i
Re: [PATCH v2 1/1] RSB: Mitigate too short error reports
Thanks Frank and Chris. I pushed the patch.
Best regards
Christian
On 2023-01-20 22:53, Chris Johns wrote:
OK to push.
Thanks
Chris
On 21/1/2023 2:06 am, Frank Kuehndel wrote:
From: Frank Kühndel
Close #4642
---
source-builder/sb/ereport.py | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/source-builder/sb/ereport.py b/source-builder/sb/ereport.py
index d8fb5f6..52ee2eb 100755
--- a/source-builder/sb/ereport.py
+++ b/source-builder/sb/ereport.py
@@ -54,7 +54,9 @@ def generate(name, opts, header = None, footer = None):
name = name.replace('/', '-')
with open(name, 'w') as l:
l.write(os.linesep.join(r))
-log.notice(' See error report: %s' % (name))
+log.notice(os.linesep.join([' See error report: %s' % (name),
+' Note: In some cases the error appears only in',
+' the complete build log (see --log option)']))
except:
log.stderr('error: failure to create error report')
raise
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
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
libbsd updates
o FreeBSD stable/12 2019-09-23 Update to FreeBSD stable/12 2019-02-11 Update to FreeBSD stable/12 2019-01-16 Update to FreeBSD head 2018-11-15 Update to FreeBSD head 2018-09-17 Update to FreeBSD head 2018-06-01 Update to FreeBSD head 2018-04-01 Update to FreeBSD head 2017-12-01 Update to FreeBSD head 2017-08-01 Update to FreeBSD head 2017-04-04 Update to FreeBSD head 2016-12-10 Update to FreeBSD head 2016-08-23 Update to FreeBSD 9.3 Update to FreeBSD 9.2 Update to FreeBSD 8.4 In general, the system call related area is not an issue during updates since the system call interface is pretty stable. System call stability is a very important thing for FreeBSD/Linux/etc. Maintainability is decided by the*next* person to work on the code. So far I am the only one who expressed plans to synchronize libbsd with the upstream FreeBSD development. It looks to me like it is considerably easier to find the RTEMS syscall layer in the consolidated approach, and to work across layers. Moving things to a separate file instead of having it directly under the implementation function is considerably easier to find? There is also a performance benefit to allow the compiler to optimize the syscall away, but that also impacts debuggability if our syscall layer disappears. If you want to debug you have to reduce the optimization level anyway. You can use for example -fno-inline. The tradeoffs between maintainability and debuggability vs performance appear to be fairly complicated in this space. There's not a great description to me yet of what is required for performance, while the documentation of libbsd has mostly favored maintainability as a primary objective. So I think that any argument to do something for performance reasons has to be accompanied by clear evidence that the performance improvement matters. Talking about maintainability here sounds fairly abstract to me. This should be underlined with concrete examples. In the master branch there is no kern_descrip.c which is a 4k LOC source file. I don't know how adding this file improves maintainability. The VFS/NFS support works without the FreeBSD file descriptors. changed without a discussion on the RTEMS mailing list. It worked for years, it allows compiler optimizations, it is easy to review, and there are no issues during updates. I think the change was announced: https://lists.rtems.org/pipermail/devel/2021-July/068573.html This is just another outcome of our current way of handling change management. Changes can easily be lost in the email exchange. Sorry, I didn't notice this e-mail before. In this time frame I was quite busy with the RTEMS pre-qualification activity and holidays. I updated the patch set so that it doesn't require changes in RTEMS: https://github.com/sebhub/rtems-libbsd/tree/filedesc I think we can then revisit whether or not the FreeBSD File Descriptors themselves are in fact problematic. File descriptors on top of file descriptors make little sense. Also FreeBSD has some implementation overheads which are unnecessary in the RTEMS context in which the maximum file descriptor count is fixed at link time. Are there any performance analyses that quantify the impact of the implementation overhead of FreeBSD File Descriptors? Again, this is about the tradeoff between maintainability and performance. i can't make value judgments about performance without understanding the resource constraints of the target platforms, and the performance metrics (code size, heap size, throughput?) that are used to decide if an optimization is worth sacrificing maintainability. It has always been my understanding that the libbsd strives for maintainability first and foremost. So to unilaterally reject code changes that reduce the maintenance burden (by keeping us closer to the vanilla FreeBSD code base) in the name of performance requires two things: 1. Evidence that the performance improvement is substantial. 2. Argument that the implementation of the performance improvement is the most maintainable way to achieve it. So far, I haven't seen either of these with respect to the runtime overheads. And I haven't seen a good argument that injecting the syscall implementations into FreeBSD is better than having them live separately in the rtemsbsd layer. If you are interested I suggest to build libbsd for the arm/xilinx_zynq_a9_qemu BSP with optimization disabled. Then step through a socket send/receive system call on the master and 6-freebsd-12 branch and in particular getsock_cap(). ===== On 2023-01-16 14:30, Christian MAUDERER wrote: Hello, I think we have a bit of a new situation here: There are two approaches to a problem, and it seems that no consent can be found with the usual discussions. May I suggest that we try a more top-down approach: Let's agree what are the important points that we want to re
Re: [PATCHES rtems, source-builder] Add GitHub Actions scripts
Am 20.01.23 um 06:21 schrieb Chris Johns: On 20/1/2023 1:50 am, Christian MAUDERER wrote: Am 19.01.23 um 15:42 schrieb Gedare Bloom: Nice. I would like some time to look at this and think about it a little more. What would be the plan for removing this capability? Will it leave any artifacts behind in the RTEMS github mirror? As soon as we want to get rid of the scripts again (because we have found and implemented a proper CI/CD that we officially want to use and not only have in a test phase), we can just remove the scripts with a new commit. If we use both commits, we will have a bot that adds a comment to pull requests, that patches should be sent to the mailing list as soon as they are tested. It will close pull requests after 30 days. That can be disabled again with removing that action. All artefacts can be removed by everyone with enough rights in the RTEMS GitHub organization. That should be most maintainers. What github account does all this happen on? Chris Hello Chris, at the moment, I have a prototype at an embedded-brains account (see links in my first mail). My suggestion is to add the scripts to the official RTEMS GitHub mirror repositories to get some feedback from users and developers what is good or bad in this prototype CI system. Based on this we should discuss in one or two months what features we need and select and implement a long-term CI system for RTEMS. 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 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
Re: [PATCHES rtems, source-builder] Add GitHub Actions scripts
Am 19.01.23 um 15:42 schrieb Gedare Bloom: Nice. I would like some time to look at this and think about it a little more. What would be the plan for removing this capability? Will it leave any artifacts behind in the RTEMS github mirror? As soon as we want to get rid of the scripts again (because we have found and implemented a proper CI/CD that we officially want to use and not only have in a test phase), we can just remove the scripts with a new commit. If we use both commits, we will have a bot that adds a comment to pull requests, that patches should be sent to the mailing list as soon as they are tested. It will close pull requests after 30 days. That can be disabled again with removing that action. All artefacts can be removed by everyone with enough rights in the RTEMS GitHub organization. That should be most maintainers. Best regards Christian On Mon, Jan 16, 2023 at 6:42 AM Christian Mauderer wrote: Hello, some weeks ago I created a GitHub Actions based CI script that we (embedded brains) wanted to use to test patches (see https://github.com/embedded-brains/rtems/tree/ci). I don't think much of the RTEMS community noted these. I would like to suggest adding the scripts to the official RTEMS repositories so that the actions are executed in the official GitHub RTEMS mirrors. To make sure that GitHub pull requests are not perceived at the official way to make RTEMS contributions, an auto-responder action notifies the pull request user that the current way to make contributions is sending patch sets to devel@rtems.org. This step will allow users to easily test patches on a number of simulators before they send them to the mailing list. No one is forced to do it, but everyone can try it. For RTEMS, it has the advantage that the patches are at least guaranteed to be compile-clean on a selected number of BSPs and that they survived a test run on a simulator. Please note: With this patch I do not intent to push GitHub as the RTEMS CI or to move from mailing list patches to push-requests. My idea is to allow everyone to experiment with a proof of concept prototype. Based on your experiences in this test phase, I would suggest that we have a review discussion in a month or two to select a suitable way forward for RTEMS CI. I think after that test phase we all know better what we want or expect which helps selecting the best CI system that then can replace this proof of concept system with GitHub. But now to make make it more clear what we will get with merging these patches: You can find a (not yet cleaned up) version of the patches in these repositories: https://github.com/embedded-brains/rtems https://github.com/embedded-brains/rtems-source-builder The results from a current run on RTEMS are here: https://github.com/embedded-brains/rtems/actions/runs/3901364934 If you scroll down on that page, you get a summary that shows which tests fail on three (mostly) randomly selected simulator BSPs. GR740 usually can run all tests but currently jffs2_fsrdwr fails. The full output of the rtems tester is in the Artifacts in case you want to take a look at the test output. If you want to try the CI with some of your patches before we merge this to the official repositories, feel free to create a pull request to the ci branches of the embedded-brains/rtems repositories. See the github manual for guidance how to create a pull request: https://docs.github.com/articles/creating-a-pull-request Note: It is important that you somewhen forked from the official RTEMS repositories or from one of the forks using (for example) the fork button in the github web interface. If you just pushed a repo to an empty one, github doesn't recognize the link and won't allow you to create a pull-request towards the embedded-brains repository. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
[PATCH rtems 1/2] github: Enable CI
Allow users to optionally use the CI from github.
---
.github/actions/build-bsps/action.yml| 49
.github/actions/run-simulator/action.yml | 144 +++
.github/workflows/bsps.yml | 63 ++
.github/workflows/simulator.yml | 72
4 files changed, 328 insertions(+)
create mode 100644 .github/actions/build-bsps/action.yml
create mode 100644 .github/actions/run-simulator/action.yml
create mode 100644 .github/workflows/bsps.yml
create mode 100644 .github/workflows/simulator.yml
diff --git a/.github/actions/build-bsps/action.yml
b/.github/actions/build-bsps/action.yml
new file mode 100644
index 00..c06e560125
--- /dev/null
+++ b/.github/actions/build-bsps/action.yml
@@ -0,0 +1,49 @@
+name: "Build BSPs"
+description: "Build BSPs for the given target architecture."
+
+inputs:
+ bsp:
+description: "The bsp to build 'sparc/erc32'"
+type: string
+required: true
+ sources-rtems:
+description: "Where to find the RTEMS sources. Use absolute path!"
+type: string
+required: true
+ prefix:
+description: "Prefix directory with the installed tools. Use absolute
path!"
+type: string
+required: true
+
+runs:
+ using: "composite"
+ steps:
+- name: create name for logs
+ shell: bash
+ run: |
+shortname=`echo "${{ inputs.bsp }}" | sed -e "s|/|_|g"`
+echo "shortname=${shortname}" >> $GITHUB_ENV
+- name: create log dir
+ shell: bash
+ run: mkdir "${GITHUB_WORKSPACE}"/bsp-logs
+- name: Run BSP builder
+ shell: bash
+ run: |
+"${{ inputs.prefix }}"/bin/rtems-bsp-builder \
+ --build-path "${GITHUB_WORKSPACE}"/rtems-build \
+ --prefix "${{ inputs.prefix }}" \
+ --rtems-tools "${{ inputs.prefix }}/bin" \
+ --rtems "${{ inputs.sources-rtems }}" \
+ --bsp ${{ inputs.bsp }} \
+ --log "${GITHUB_WORKSPACE}"/bsp-logs/log-${{
env.shortname }}.txt \
+ --warnings-report
"${GITHUB_WORKSPACE}"/bsp-logs/warnings-${{ env.shortname }}.txt \
+ --failures-report
"${GITHUB_WORKSPACE}"/bsp-logs/failures-${{ env.shortname }}.txt
+- name: Archive log
+ uses: actions/upload-artifact@v3
+ with:
+name: log-${{ env.shortname }}
+path: bsp-logs
+- name: Check for errors
+ shell: bash
+ run: |
+grep "Failures: 0" "$GITHUB_WORKSPACE"/bsp-logs/log-${{ env.shortname
}}.txt
diff --git a/.github/actions/run-simulator/action.yml
b/.github/actions/run-simulator/action.yml
new file mode 100644
index 00..23aa70e8ea
--- /dev/null
+++ b/.github/actions/run-simulator/action.yml
@@ -0,0 +1,144 @@
+name: "Run Simulator"
+description: "Build BSPs for the given target/BSP and run tests on a simulator"
+
+inputs:
+ target:
+description: "The Arch/BSP to run. For example 'sparc/erc32'"
+type: string
+required: true
+ sources-rtems:
+description: "Where to find the RTEMS sources. Use absolute path!"
+type: string
+required: true
+ prefix:
+description: "Prefix directory with the installed tools. Use absolute
path!"
+type: string
+required: true
+
+runs:
+ using: "composite"
+ steps:
+- shell: bash
+ run: |
+# Find correct parameters for this simulator
+args=""
+found=0
+[ "${{ inputs.target }}" == "sparc/erc32" ] && \
+ args="--rtems-bsp=erc32-sis" && \
+ found=1
+[ "${{ inputs.target }}" == "sparc/gr740" ] && \
+ args="--rtems-bsp=gr740-sis" && \
+ found=1
+[ "${{ inputs.target }}" == "riscv/griscv" ] && \
+ args="--rtems-bsp=griscv-sis" && \
+ found=1
+[ "${{ inputs.target }}" == "arm/xilinx_zynq_a9_qemu" ] && \
+ args="--rtems-bsp=xilinx_zynq_a9_qemu" && \
+ found=1
+echo "rtems_test_args=${args}" >> $GITHUB_ENV
+echo "simulator_supported=${found}" >> $GITHUB_ENV
+- if: ${{ env.simulator_supported == 0 }}
+ shell: bash
+ run: |
+# Check whether parameters for this simulator have been found
+echo "${{ inputs.target }} is not supported for simulator runs"
+false
+- shell: bash
+ run: |
+# create environment variables for paths and names
+shortname=`echo "${{ inputs.target }}" | sed -e "s|/|_|g"`
+echo "shortname=${shortname}" >> $GITHUB_ENV
+echo "logdir=${GITHUB_WORKSPACE}/logs-${shortname}" >> $GITHUB_ENV
+echo "builddir=${GITHUB_WORKSPACE}/build-${shortname}" >> $GITHUB_ENV
+- shell: bash
+ run: |
+# create directories
+mkdir -p "${{ env.logdir }}"
+mkdir -p "${{ env.builddir }}"
+- shell: bash
+ run: |
+# generate BSP config
+echo -e "[${{
[PATCH rtems-source-builder 2/2] github: Mark pull requests as stale
Mark all new pull requests as stale. Add a note that the CI can be used but that patches should be sent to the mailing list instead. Close pull requests after 30 days. --- .github/workflows/mark-stale.yml | 23 +++ 1 file changed, 23 insertions(+) create mode 100644 .github/workflows/mark-stale.yml diff --git a/.github/workflows/mark-stale.yml b/.github/workflows/mark-stale.yml new file mode 100644 index 000..9fd22d2 --- /dev/null +++ b/.github/workflows/mark-stale.yml @@ -0,0 +1,23 @@ +name: 'Mark all PRs as stale' +on: + pull_request: +types: [opened] + schedule: +- cron: '28 6 * * *' + workflow_dispatch: + +permissions: + issues: write + pull-requests: write + +jobs: + stale: +runs-on: ubuntu-latest +steps: + - uses: actions/stale@v7 +with: + stale-pr-message: 'Please note that Pull Requests are neither merged nor reviewed! Your Pull Requests only trigger continuous integration builds and tests in this repository and will automatically be closed after a month. As soon as you are happy with the result, please send the patches to the mailing list at devel@rtems.org. See https://lists.rtems.org for instructions how to register for that list. Thank you. ' + days-before-stale: -1 + days-before-close: -1 + days-before-pr-stale: 0 + days-before-pr-close: 30 -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-source-builder 1/2] github: Enable CI
Allow users to optionally use the GitHub CI.
---
.github/workflows/toolchain.yml | 196
1 file changed, 196 insertions(+)
create mode 100644 .github/workflows/toolchain.yml
diff --git a/.github/workflows/toolchain.yml b/.github/workflows/toolchain.yml
new file mode 100644
index 000..f9fec95
--- /dev/null
+++ b/.github/workflows/toolchain.yml
@@ -0,0 +1,196 @@
+name: Toolchain
+
+on:
+ # Triggers the workflow on push or pull request for the given branch
+ push:
+branches: [ master ]
+ pull_request:
+branches: [ master ]
+
+ # Trigger manually from the Actions tab
+ workflow_dispatch:
+
+jobs:
+ devel:
+strategy:
+ fail-fast: false
+ matrix:
+tool:
+ - autotools-base
+ - autotools
+ - capstone
+ - dtc
+ - gnu-default-tools
+ - libtool
+ - libusb
+ - or1ksim
+ - qemu-couverture
+ - qemu-xilinx
+ - qemu
+ - sis
+ - spike
+ - swig
+runs-on: ubuntu-latest
+steps:
+ - uses: actions/checkout@v3
+with:
+ path: rsb
+ - name: Install dependencies
+run: |
+ sudo apt-get update
+ sudo apt-get install \
+build-essential \
+ninja-build \
+libudev-dev
+ - name: Build ${{ matrix.tool }}
+run: |
+ cd rsb/rtems
+ ../source-builder/sb-set-builder \
+--log=l-${{ matrix.tool }} \
+--prefix=/opt/rtems/6 \
+--bset-tar-file \
+devel/${{ matrix.tool }}
+ - name: Archive log on failure
+if: ${{ failure() }}
+uses: actions/upload-artifact@v3
+with:
+ name: log-${{ matrix.tool }}
+ path: |
+rsb/rtems/l-${{ matrix.tool }}
+rsb/**/rsb-report-*.txt
+ - name: Archive artifacts
+uses: actions/upload-artifact@v3
+with:
+ name: devel-${{ matrix.tool }}
+ path: rsb/rtems/tar/*.tar*
+
+ build:
+strategy:
+ fail-fast: false
+ matrix:
+target:
+ - aarch64
+ - arm
+ - bfin
+ - i386
+ - lm32
+ - m68k
+ - microblaze
+ - mips
+ - moxie
+ - nios2
+ - or1k
+ - powerpc
+ - riscv
+ - sh
+ - sparc
+ - sparc64
+ - v850
+ - x86_64
+runs-on: ubuntu-latest
+steps:
+ - uses: actions/checkout@v3
+with:
+ path: rsb
+ - uses: actions/checkout@v3
+with:
+ path: rtems
+ ref: ci
+ repository: RTEMS/rtems
+ - name: Install dependencies
+run: |
+ sudo apt-get update
+ sudo apt-get install \
+build-essential \
+flex \
+bison \
+cmake \
+texinfo \
+device-tree-compiler \
+u-boot-tools \
+lzop \
+libusb-1.0-0-dev \
+python3 \
+python-is-python3 \
+libpython3-dev \
+python3-dev
+ - name: Build toolchain
+run: |
+ cd rsb/rtems
+ ../source-builder/sb-set-builder \
+--log=l-${{ matrix.target }} \
+--prefix=/opt/rtems/6 \
+--bset-tar-file \
+6/rtems-${{ matrix.target }}
+ - name: Archive log on failure
+if: ${{ failure() }}
+uses: actions/upload-artifact@v3
+with:
+ name: log-${{ matrix.target }}
+ path: rsb/rtems/l-${{ matrix.target }}
+ - name: Archive artifacts
+uses: actions/upload-artifact@v3
+with:
+ name: tools-${{ matrix.target }}
+ path: rsb/rtems/tar/*.tar*
+ #- name: Build BSPs
+ # uses: ./rtems/.github/actions/build-bsps
+ # with:
+ #target: ${{ matrix.target }}
+ #sources-rtems: "${GITHUB_WORKSPACE}/rtems"
+ #prefix: /opt/rtems/6
+
+ simulator:
+# run even if not all of the earlier matrix builds worked
+if: ${{ always() }}
+needs:
+ - build
+ - devel
+strategy:
+ fail-fast: false
+ matrix:
+simulators:
+ - sparc/gr740
+ - riscv/griscv
+ - arm/xilinx_zynq_a9_qemu
+runs-on: ubuntu-latest
+steps:
+ - name: split arch and BSP
+shell: bash
+run: |
+ arch=`echo "${{ matrix.simulators }}" | sed -e "s|/.*||g"`
+ bsp=`echo "${{ matrix.simulators }}" | sed -e "s|.*/||g"`
+ echo "arch=${arch}" >> $GITHUB_ENV
+ echo "bsp=${bsp}" >> $GITHUB_ENV
+ - uses: actions/checkout@v3
+with:
+ path: rtems
+ ref: ci
+ repository: RTEMS/rtems
+ - name: Install dependencies
+run: |
+ sudo apt-get update
+ sudo apt-get install \
+python3 \
+
[PATCH rtems 2/2] github: Mark pull requests as stale
Mark all new pull requests as stale. Add a note that the CI can be used but that patches should be sent to the mailing list instead. Close pull requests after 30 days. --- .github/workflows/mark-stale.yml | 23 +++ 1 file changed, 23 insertions(+) create mode 100644 .github/workflows/mark-stale.yml diff --git a/.github/workflows/mark-stale.yml b/.github/workflows/mark-stale.yml new file mode 100644 index 00..9fd22d240b --- /dev/null +++ b/.github/workflows/mark-stale.yml @@ -0,0 +1,23 @@ +name: 'Mark all PRs as stale' +on: + pull_request: +types: [opened] + schedule: +- cron: '28 6 * * *' + workflow_dispatch: + +permissions: + issues: write + pull-requests: write + +jobs: + stale: +runs-on: ubuntu-latest +steps: + - uses: actions/stale@v7 +with: + stale-pr-message: 'Please note that Pull Requests are neither merged nor reviewed! Your Pull Requests only trigger continuous integration builds and tests in this repository and will automatically be closed after a month. As soon as you are happy with the result, please send the patches to the mailing list at devel@rtems.org. See https://lists.rtems.org for instructions how to register for that list. Thank you. ' + days-before-stale: -1 + days-before-close: -1 + days-before-pr-stale: 0 + days-before-pr-close: 30 -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCHES rtems, source-builder] Add GitHub Actions scripts
Hello, some weeks ago I created a GitHub Actions based CI script that we (embedded brains) wanted to use to test patches (see https://github.com/embedded-brains/rtems/tree/ci). I don't think much of the RTEMS community noted these. I would like to suggest adding the scripts to the official RTEMS repositories so that the actions are executed in the official GitHub RTEMS mirrors. To make sure that GitHub pull requests are not perceived at the official way to make RTEMS contributions, an auto-responder action notifies the pull request user that the current way to make contributions is sending patch sets to devel@rtems.org. This step will allow users to easily test patches on a number of simulators before they send them to the mailing list. No one is forced to do it, but everyone can try it. For RTEMS, it has the advantage that the patches are at least guaranteed to be compile-clean on a selected number of BSPs and that they survived a test run on a simulator. Please note: With this patch I do not intent to push GitHub as the RTEMS CI or to move from mailing list patches to push-requests. My idea is to allow everyone to experiment with a proof of concept prototype. Based on your experiences in this test phase, I would suggest that we have a review discussion in a month or two to select a suitable way forward for RTEMS CI. I think after that test phase we all know better what we want or expect which helps selecting the best CI system that then can replace this proof of concept system with GitHub. But now to make make it more clear what we will get with merging these patches: You can find a (not yet cleaned up) version of the patches in these repositories: https://github.com/embedded-brains/rtems https://github.com/embedded-brains/rtems-source-builder The results from a current run on RTEMS are here: https://github.com/embedded-brains/rtems/actions/runs/3901364934 If you scroll down on that page, you get a summary that shows which tests fail on three (mostly) randomly selected simulator BSPs. GR740 usually can run all tests but currently jffs2_fsrdwr fails. The full output of the rtems tester is in the Artifacts in case you want to take a look at the test output. If you want to try the CI with some of your patches before we merge this to the official repositories, feel free to create a pull request to the ci branches of the embedded-brains/rtems repositories. See the github manual for guidance how to create a pull request: https://docs.github.com/articles/creating-a-pull-request Note: It is important that you somewhen forked from the official RTEMS repositories or from one of the forks using (for example) the fork button in the github web interface. If you just pushed a repo to an empty one, github doesn't recognize the link and won't allow you to create a pull-request towards the embedded-brains repository. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 2/3] bsps/atsam: Add NULL pointer protection
---
bsps/arm/atsam/README | 6 +-
.../libraries/libboard/source/board_lowlevel.c | 17 +
bsps/arm/atsam/include/bsp.h| 4
bsps/arm/atsam/include/libchip/include/mpu.h| 1 +
bsps/arm/atsam/start/bspstarthooks.c| 2 +-
spec/build/bsps/arm/atsam/bspatsam.yml | 2 ++
spec/build/bsps/arm/atsam/linkcmds.yml | 7 ++-
spec/build/bsps/arm/atsam/optnullsz.yml | 17 +
spec/build/bsps/arm/atsam/opttcmsz.yml | 3 ++-
9 files changed, 55 insertions(+), 4 deletions(-)
create mode 100644 spec/build/bsps/arm/atsam/optnullsz.yml
diff --git a/bsps/arm/atsam/README b/bsps/arm/atsam/README
index 2ebaa726c8..47aa11d2c0 100644
--- a/bsps/arm/atsam/README
+++ b/bsps/arm/atsam/README
@@ -59,9 +59,13 @@ Use ATSAM_CONSOLE_DEVICE_INDEX=XYZ to set the device index
for /dev/console
Use ATSAM_CONSOLE_USE_INTERRUPTS=XYZ to set the use interrupt driven mode for
console devices (used by default).
-Use ATSAM_MEMORY_TCM_SIZE=XYZ to set the size of tightly coupled memories (TCM)
+Use ATSAM_MEMORY_NULL_SIZE=XYZ to set the size of NULL pointer protection area
in bytes (default 0x).
+Use ATSAM_MEMORY_TCM_SIZE=XYZ to set the size of tightly coupled memories (TCM)
+in bytes (default 0x). Note: ITCM is reduced by the
+ATSAM_MEMORY_NULL_SIZE.
+
Use ATSAM_MEMORY_INTFLASH_SIZE=XYZ to set the size of internal flash in bytes
(default is derived from chip variant).
diff --git a/bsps/arm/atsam/contrib/libraries/libboard/source/board_lowlevel.c
b/bsps/arm/atsam/contrib/libraries/libboard/source/board_lowlevel.c
index cbdf41ba73..a2dd595fb5 100644
--- a/bsps/arm/atsam/contrib/libraries/libboard/source/board_lowlevel.c
+++ b/bsps/arm/atsam/contrib/libraries/libboard/source/board_lowlevel.c
@@ -347,6 +347,23 @@ void _SetupMemoryRegion(void)
SCB->SHCSR |= (SCB_SHCSR_MEMFAULTENA_Msk | SCB_SHCSR_BUSFAULTENA_Msk
| SCB_SHCSR_USGFAULTENA_Msk);
+#ifdef __rtems__
+ dwRegionBaseAddr =
+ ((uintptr_t)atsam_memory_null_begin) |
+ MPU_REGION_VALID |
+ MPU_NULL_REGION;
+ if (atsam_memory_null_begin != atsam_memory_itcm_end) {
+ dwRegionAttr =
+ MPU_AP_NO_ACCESS |
+ MPU_REGION_EXECUTE_NEVER |
+ MPU_CalMPURegionSize((uintptr_t)atsam_memory_null_size)
|
+ MPU_REGION_ENABLE;
+ } else {
+ dwRegionAttr = MPU_REGION_DISABLE;
+ }
+ MPU_SetRegion(dwRegionBaseAddr, dwRegionAttr);
+#endif /* __rtems__ */
+
/* Enable the MPU region */
#ifndef __rtems__
MPU_Enable(MPU_ENABLE | MPU_PRIVDEFENA);
diff --git a/bsps/arm/atsam/include/bsp.h b/bsps/arm/atsam/include/bsp.h
index 8fe98be364..0bca3d2c22 100644
--- a/bsps/arm/atsam/include/bsp.h
+++ b/bsps/arm/atsam/include/bsp.h
@@ -89,6 +89,10 @@ typedef struct {
uint8_t phy_addr;
} if_atsam_config;
+extern char atsam_memory_null_begin[];
+extern char atsam_memory_null_end[];
+extern char atsam_memory_null_size[];
+
extern char atsam_memory_dtcm_begin[];
extern char atsam_memory_dtcm_end[];
extern char atsam_memory_dtcm_size[];
diff --git a/bsps/arm/atsam/include/libchip/include/mpu.h
b/bsps/arm/atsam/include/libchip/include/mpu.h
index a5d00a681b..034ba58474 100644
--- a/bsps/arm/atsam/include/libchip/include/mpu.h
+++ b/bsps/arm/atsam/include/libchip/include/mpu.h
@@ -56,6 +56,7 @@
#endif
#define MPU_SYSTEM_REGION (12)
#ifdef __rtems__
+#define MPU_NULL_REGION (13)
/* Reserve the region with highest priority for user applications */
#define MPU_USER_DEFINED_REGION (15)
#endif /* __rtems__ */
diff --git a/bsps/arm/atsam/start/bspstarthooks.c
b/bsps/arm/atsam/start/bspstarthooks.c
index 516b86228d..2be2fc050b 100644
--- a/bsps/arm/atsam/start/bspstarthooks.c
+++ b/bsps/arm/atsam/start/bspstarthooks.c
@@ -106,7 +106,7 @@ static void configure_tcm(void)
uintptr_t tcm_size;
uint32_t itcmcr_sz;
- tcm_size = (uintptr_t) atsam_memory_itcm_size;
+ tcm_size = (uintptr_t) atsam_memory_dtcm_size;
itcmcr_sz = (SCB->ITCMCR & SCB_ITCMCR_SZ_Msk) >> SCB_ITCMCR_SZ_Pos;
if (tcm_setup_and_check_if_do_efc_config(tcm_size, itcmcr_sz)) {
diff --git a/spec/build/bsps/arm/atsam/bspatsam.yml
b/spec/build/bsps/arm/atsam/bspatsam.yml
index 6716bea248..679889d253 100644
--- a/spec/build/bsps/arm/atsam/bspatsam.yml
+++ b/spec/build/bsps/arm/atsam/bspatsam.yml
@@ -296,6 +296,8 @@ links:
uid: optmck
- role: build-dependency
uid: optnocachesz
+- role: build-dependency
+ uid: optnullsz
- role: build-dependency
uid: optoscmain
- role: build-dependency
diff --git a/spec/build/bsps/arm/atsam/linkcmds.yml
b/spec/build/bsps/arm/atsam/linkcmds.yml
index fe6211f82f..d475b6a245 100644
--- a/spec/build/bsps/arm/atsam/linkcmds.yml
+++
[PATCH rtems 1/3] bsps/atsam: Fix unidirectional SPI transfers
A SPI transfer where the Rx or Tx buffer is set to NULL currently
transfers or overwrites data starting from address 0x via DMA.
This patch changes the DMA setup so that dummy transfers are done.
Just reading / writing to a single location is simpler than changing the
whole logic of the transfer depending on the passed buffers.
---
bsps/arm/atsam/spi/atsam_spi_bus.c | 188 -
1 file changed, 131 insertions(+), 57 deletions(-)
diff --git a/bsps/arm/atsam/spi/atsam_spi_bus.c
b/bsps/arm/atsam/spi/atsam_spi_bus.c
index 53c1fe4827..dcf1397043 100644
--- a/bsps/arm/atsam/spi/atsam_spi_bus.c
+++ b/bsps/arm/atsam/spi/atsam_spi_bus.c
@@ -41,8 +41,8 @@
#define MAX_SPI_FREQUENCY 5000
typedef struct {
- volatile LinkedListDescriporView0 tx_desc;
- volatile LinkedListDescriporView0 rx_desc[3];
+ volatile LinkedListDescriporView2 tx_desc;
+ volatile LinkedListDescriporView2 rx_desc[3];
uint8_t rx_bounce_head_buf[CPU_CACHE_LINE_BYTES];
uint8_t rx_bounce_tail_buf[CPU_CACHE_LINE_BYTES];
} atsam_spi_dma;
@@ -67,6 +67,8 @@ typedef struct {
uint32_t spi_csr[4];
} atsam_spi_bus;
+static const uint32_t atsam_spi_dummy_write_data = 0x;
+
static void atsam_spi_wakeup_task(atsam_spi_bus *bus)
{
rtems_binary_semaphore_post(>sem);
@@ -181,14 +183,14 @@ static void atsam_spi_copy_rx_bounce_bufs(
}
}
-static void atsam_spi_setup_rx_dma_desc(
+static void atsam_spi_setup_real_rx_dma_desc(
atsam_spi_bus *bus,
atsam_spi_dma *dma,
const uint8_t *buf,
size_t n
)
{
- volatile LinkedListDescriporView0 *desc;
+ volatile LinkedListDescriporView2 *desc;
uintptr_t m;
uintptr_t b;
uintptr_t a;
@@ -202,53 +204,56 @@ static void atsam_spi_setup_rx_dma_desc(
a = (b + m) & ~m;
ae = e & ~m;
+ /* An earlier dummy read maybe has set the DAM to FIXED_AM. Reset it. */
+ desc[0].mbr_cfg =
+ (desc[0].mbr_cfg & ~XDMAC_CC_DAM_Msk) | XDMAC_CC_DAM_INCREMENTED_AM;
if (n <= m) {
bus->rx_bounce_head_len = n;
bus->rx_bounce_tail_len = 0;
-desc[0].mbr_ta = (uint32_t) dma->rx_bounce_head_buf;
-desc[0].mbr_ubc = n;
+desc[0].mbr_da = (uint32_t) dma->rx_bounce_head_buf;
+desc[0].mbr_ubc = n | XDMA_UBC_NVIEW_NDV2;
} else {
bus->rx_bounce_head_len = a - b;
bus->rx_bounce_tail_len = e & m;
if ((b & m) == 0) {
if ((n & m) == 0) {
-desc[0].mbr_ta = a;
-desc[0].mbr_ubc = n;
+desc[0].mbr_da = a;
+desc[0].mbr_ubc = n | XDMA_UBC_NVIEW_NDV2;
} else {
-desc[0].mbr_ta = a;
+desc[0].mbr_da = a;
desc[0].mbr_ubc = (ae - a) | XDMA_UBC_NDEN_UPDATED
- | XDMA_UBC_NVIEW_NDV0
+ | XDMA_UBC_NVIEW_NDV2
| XDMA_UBC_NDE_FETCH_EN;
-desc[1].mbr_ta = (uint32_t) dma->rx_bounce_tail_buf;
-desc[1].mbr_ubc = n & m;
+desc[1].mbr_da = (uint32_t) dma->rx_bounce_tail_buf;
+desc[1].mbr_ubc = n & m | XDMA_UBC_NVIEW_NDV2;
}
} else {
if ((e & m) == 0) {
-desc[0].mbr_ta = (uint32_t) dma->rx_bounce_head_buf;
+desc[0].mbr_da = (uint32_t) dma->rx_bounce_head_buf;
desc[0].mbr_ubc = (a - b) | XDMA_UBC_NDEN_UPDATED
- | XDMA_UBC_NVIEW_NDV0
+ | XDMA_UBC_NVIEW_NDV2
| XDMA_UBC_NDE_FETCH_EN;
-desc[1].mbr_ta = a;
-desc[1].mbr_ubc = ae - a;
+desc[1].mbr_da = a;
+desc[1].mbr_ubc = ae - a | XDMA_UBC_NVIEW_NDV2;
} else if ((ae - a) == 0) {
bus->rx_bounce_head_len = n;
bus->rx_bounce_tail_len = 0;
-desc[0].mbr_ta = (uint32_t) dma->rx_bounce_head_buf;
-desc[0].mbr_ubc = n;
+desc[0].mbr_da = (uint32_t) dma->rx_bounce_head_buf;
+desc[0].mbr_ubc = n | XDMA_UBC_NVIEW_NDV2;
} else {
-desc[0].mbr_ta = (uint32_t) dma->rx_bounce_head_buf;
+desc[0].mbr_da = (uint32_t) dma->rx_bounce_head_buf;
desc[0].mbr_ubc = (a - b) | XDMA_UBC_NDEN_UPDATED
- | XDMA_UBC_NVIEW_NDV0
+ | XDMA_UBC_NVIEW_NDV2
| XDMA_UBC_NDE_FETCH_EN;
-desc[1].mbr_ta = a;
+desc[1].mbr_da = a;
desc[1].mbr_ubc = (ae - a) | XDMA_UBC_NDEN_UPDATED
- | XDMA_UBC_NVIEW_NDV0
+ | XDMA_UBC_NVIEW_NDV2
| XDMA_UBC_NDE_FETCH_EN;
-desc[2].mbr_ta = (uint32_t) dma->rx_bounce_tail_buf;
-desc[2].mbr_ubc = e - ae;
+desc[2].mbr_da = (uint32_t) dma->rx_bounce_tail_buf;
+desc[2].mbr_ubc = e - ae | XDMA_UBC_NVIEW_NDV2;
}
}
@@ -256,19 +261,61 @@ static void atsam_spi_setup_rx_dma_desc(
}
}
+static void atsam_spi_setup_dummy_rx_dma_desc(
+ atsam_spi_bus *bus,
+ atsam_spi_dma *dma,
+ size_t n
+)
+{
+ volatile LinkedListDescriporView2 *desc;
+
+ desc = >rx_desc[0];
+
+ /* Avoid copying bounce buffers after receive. */
+ bus->rx_bounce_head_len = 0;
+ bus->rx_bounce_tail_len = 0;
+
+ /* But use one of the bounce buffers to write dummy data to. */
+ desc[0].mbr_da =
[PATCH rtems 3/3] bsp/atsam: Allow to use custom SDRAM
With the old build system in RTEMS 5 that was possible by just
overwriting BOARD_Sdram_Config and setting a custom
ATSAM_MEMORY_SDRAM_SIZE during building the BSP. In the new build system
that ATSAM_MEMORY_SDRAM_SIZE is set exclusively by the selected SDRAM
chip.
This patch adds the possibility to specify a "custom-0x10" or
similar as SDRAM type where the number gives the SDRAM size.
---
bsps/arm/atsam/start/sdram-config.c| 7 +++
spec/build/bsps/arm/atsam/optsdram.yml | 21 -
2 files changed, 23 insertions(+), 5 deletions(-)
diff --git a/bsps/arm/atsam/start/sdram-config.c
b/bsps/arm/atsam/start/sdram-config.c
index 87e52ebed0..85b009a9d5 100644
--- a/bsps/arm/atsam/start/sdram-config.c
+++ b/bsps/arm/atsam/start/sdram-config.c
@@ -148,6 +148,13 @@ const struct BOARD_Sdram_Config BOARD_Sdram_Config = {
#error Please check SDRAM settings for this frequency.
#endif
+#elif defined ATSAM_SDRAM_CUSTOM
+/*
+ * Custom SDRAM defined. Provide only a dummy BOARD_Sdram_Config. This config
+ * won't work and is only there so that test applications can link. The
+ * application has to overwrite this BOARD_Sdram_Config!
+ */
+const struct BOARD_Sdram_Config BOARD_Sdram_Config = {};
#else
#error SDRAM not supported.
#endif
diff --git a/spec/build/bsps/arm/atsam/optsdram.yml
b/spec/build/bsps/arm/atsam/optsdram.yml
index c07edd9ba5..0c3808ab2b 100644
--- a/spec/build/bsps/arm/atsam/optsdram.yml
+++ b/spec/build/bsps/arm/atsam/optsdram.yml
@@ -9,10 +9,18 @@ actions:
"mt48lc16m16a2p-6a": ("ATSAM_SDRAM_MT48LC16M16A2P_6A", 0x0200),
}
if value:
-try:
-s = sdram[value]
-except:
-conf.fatal("Unkown SDRAM variant '{}'".format(value))
+if value.startswith("custom-"):
+name = "ATSAM_SDRAM_CUSTOM"
+try:
+size = int(value[len("custom-"):], base=0)
+s = (name, size)
+except Exception as e:
+conf.fatal("Invalid SDRAM size '{}': {}".format(value, e))
+else:
+try:
+s = sdram[value]
+except:
+conf.fatal("Unkown SDRAM variant '{}'".format(value))
conf.define_cond(s[0], True)
conf.env["ATSAM_MEMORY_SDRAM_SIZE"] = s[1]
build-type: option
@@ -21,7 +29,10 @@ copyrights:
default: is42s16100e-7bli
default-by-variant: []
description: |
- SDRAM variant
+ SDRAM variant. Known chips are "is42s16100e-7bli", "is42s16320f-7bl",
+ "mt48lc16m16a2p-6a". You can also set this to "custom-" (for
example
+ "custom-0x100" for a 16MiB RAM). In that case the BOARD_Sdram_Config has
+ to be overwritten by the application to get working applications.
enabled-by: true
format: '{}'
links: []
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems 0/3] bsps/atsam: Various small improvements
Hello, this patch set adds a number of improvements to the ATSAM BSP. The patches accumulated over the last few month on a branch. The first one fixes a problem with unidirectional SPI transfers. The current driver would overwrite or send data at / from 0x00. The second one adds a small protection for the NULL pointer. The last one adds the ability to use a custom SDRAM configuration and size. That was possible on RTEMS 5 by overwriting some of the configure variables during build and the RAM configuration structure in the application. With the new build system, the variables now depend purely on the RAM chip and can't be overwritten any more. This adds a possibility for a custom RAM size again. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Fwd: Identify 3rd party source in spec?
Hello Chris, Am 01.11.22 um 22:08 schrieb Chris Johns: On 2/11/2022 3:25 am, o...@c-mauderer.de wrote:> Is it a good idea to make it a mandatory attribute? It makes the yaml files bigger. It will only mean that we have to look for copy and paste bugs instead of missing attributes if someone adds a new third party library. Can you avoid having to add the item to all? I am no spec build system expert (having invested time) and seem to remember needing to hit a lot of files when adding something ... https://git.rtems.org/rtems/commit/?id=6f2aa8ad36e3aaffc9fa2cb8c744b04da7339ee2 Chris The documentation mentions at least some optional attributes in the specification files. For example "format" in a build option item or the "do-configure" in a build script item: https://docs.rtems.org/branches/master/eng/req/items.html#build-option-item-type https://docs.rtems.org/branches/master/eng/req/items.html#build-script-item-type But I think the wscript has to take into account that the value might not exist. I'm not sure whether it does that for the existing "optional" attributes. For example my first guess would be that the "do-configure" could throw a KeyError: https://git.rtems.org/rtems/tree/wscript#n1127 def do_configure(self, conf, cic): script = self.data["do-configure"] if script: exec(script) Usually I would have expected the following code instead: def do_configure(self, conf, cic): try: script = self.data["do-configure"] except KeyError: script = None if script: exec(script) So I can't clearly answer your question. I would have to try it. But regardless whether there are currently such options or not: They shouldn't be hard to implement. I just hope that this doesn't break some use case. I'll try to remember to ask Sebastian about it next week. 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 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
Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring
Hello Chris, Am 27.10.22 um 23:55 schrieb Chris Johns: Hi Christian, Thank you for your considered comments. On 27/10/2022 12:06 am, Christian MAUDERER wrote: Am 26.10.22 um 01:06 schrieb Chris Johns: On 26/10/2022 4:46 am, Joel Sherrill wrote: In general, our current approach is quite a hack. We should do things more event driven. For example, if you want to update the RSB, then you create a pull request. This pull request starts a CI script which updates the mirrors and builds the RSB on a selected set of platforms. If everything is all right, the pull request can be merged. Just getting to the point where a pull request triggered an update would be useful. Assuming a pull request with no content would be ok. I feel starting to have pull requests will only result in changes being posted there by users who see pull requests as active. It is reasonable for a user to think this. Who will then field those and merge them? Chris Hello Chris, I agree that as long as the RTEMS project doesn't officially use pull requests, it's not a good idea to have something that looks official but isn't used. On the other hand, I think that it would be a really good idea for the RTEMS project to migrate to a patch management system where a pull-request with automated CI run is the official method for contributing. I would love a patch management system to be in place. Getting consensus on what to use, how we host it, who does the work and who maintains it is hard. Yes, the consensus on what to use is the hardest part. Depending on the system there is more or less maintainence necessary. For the implementation I would strongly vote for a system that uses in-repo configuration files like the .gitlab.yml or .github directory (or many others) because it allows everyone to contribute. This also means that if (for example) I introduces a breaking change, I have to adapt the CI myself. I can't just say "I'm not able to adapt it. Sorry." That would take a lot of work from the shoulders of the maintainers because for a lot of patches, no more manual tests whether the patch builds would be necessary. Of course the patch would still need review. No question that would be the case. A good tool will also manage CI to make sure we have buildable commits entering the repo. Beneath that, a system with pull requests usually has a nice overview over pending patches. At the moment we have patches on the mailing list mixed with discussions. Yes this is true and I would like to add pull requests are widely used and people know how to use them and trust them and this is important for us long term. We need to stay current in the tools and methods we employ. > A user has to get the attention of a maintainer to get a patch merged. Users that don't want to be pushy maybe don't ping such patches or some might just forget that they send a patch to the list. Agreed. I am guilty of forgetting. I'm sure that we lost quite a few patches due to that because no one felt responsible, no one noted the patch or no one had the time to test the patches before merging them. I also think this is true. I know that I have even lost some of my own patches on the list because no one acknoledged them and I started to work on something else and forget them. I found some a few months later and was surprised that I didn't push them. I wouldn't guarantee that I found all of them. A patch management system should help to see whether there are still open ones. Good to know I am not the only one. PS: I already mentioned it in another mail: I started to build some github CI scripts that we at embedded brains want to use for testing our own public patches. Github doesn't seem to limit the CI time on public projects so everyone who wants to play a bit with it: Feel free to create pull requests to see how something like that works. Just select the "ci" branch on https://github.com/embedded-brains/rtems That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I don't see the risk that someone mixes it up with the official repos. But if unknown users will use it to create pull requests, I'll add a comment to the pull requests, that patches should be sent to the mailing list instead. If there are a lot of unknown users, I'll automate the comments. Yes I remember, maybe on discord. I took a look and it is nice. It is great to see support companies running CI flows. OAR has tools builds and simulator test runs posting to build results to the builds list and this is great and important. As soon as the system stabelizes, I might can set up the CI on the main branch (not pull-requests) to send mails to the list too. But I would like to test it a bit further before I start spamming the list accidentaly. I would like to see more hardware test runs and posted results. Does EB have any plans to run the testsuite on hardware and post the results to build
Re: Increase Frequency of Updates of RTEMS GitHub Tools Mirroring
Am 26.10.22 um 01:06 schrieb Chris Johns: On 26/10/2022 4:46 am, Joel Sherrill wrote: In general, our current approach is quite a hack. We should do things more event driven. For example, if you want to update the RSB, then you create a pull request. This pull request starts a CI script which updates the mirrors and builds the RSB on a selected set of platforms. If everything is all right, the pull request can be merged. Just getting to the point where a pull request triggered an update would be useful. Assuming a pull request with no content would be ok. I feel starting to have pull requests will only result in changes being posted there by users who see pull requests as active. It is reasonable for a user to think this. Who will then field those and merge them? Chris Hello Chris, I agree that as long as the RTEMS project doesn't officially use pull requests, it's not a good idea to have something that looks official but isn't used. On the other hand, I think that it would be a really good idea for the RTEMS project to migrate to a patch management system where a pull-request with automated CI run is the official method for contributing. That would take a lot of work from the shoulders of the maintainers because for a lot of patches, no more manual tests whether the patch builds would be necessary. Of course the patch would still need review. Beneath that, a system with pull requests usually has a nice overview over pending patches. At the moment we have patches on the mailing list mixed with discussions. A user has to get the attention of a maintainer to get a patch merged. Users that don't want to be pushy maybe don't ping such patches or some might just forget that they send a patch to the list. I'm sure that we lost quite a few patches due to that because no one felt responsible, no one noted the patch or no one had the time to test the patches before merging them. I know that I have even lost some of my own patches on the list because no one acknoledged them and I started to work on something else and forget them. I found some a few months later and was surprised that I didn't push them. I wouldn't guarantee that I found all of them. A patch management system should help to see whether there are still open ones. PS: I already mentioned it in another mail: I started to build some github CI scripts that we at embedded brains want to use for testing our own public patches. Github doesn't seem to limit the CI time on public projects so everyone who wants to play a bit with it: Feel free to create pull requests to see how something like that works. Just select the "ci" branch on https://github.com/embedded-brains/rtems That repo is clearly a fork (marked with "forked from RTEMS/rtems" so I don't see the risk that someone mixes it up with the official repos. But if unknown users will use it to create pull requests, I'll add a comment to the pull requests, that patches should be sent to the mailing list instead. If there are a lot of unknown users, I'll automate the comments. 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 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
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 08:48 schrieb Chris Johns: On 30/9/2022 4:08 pm, Christian MAUDERER wrote: Am 30.09.22 um 07:37 schrieb Chris Johns: On 30/9/2022 3:33 pm, Christian MAUDERER wrote: Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris I'm currently trying to create a basic CI/CD setup for testing our embedded brains patches using GitHub. At the moment it's still quite experimental and still a bit thrown together but it basically runs: https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 Nice. It didn't catch that bug because it doesn't use installed tools for the simulator runs, but maybe I can change that. If it works well enough, we maybe could re-use some scripts or work flows to set up an official RTEMS CI/CD with whatever community preferred CI system. It shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or any other modern CI system. I have started https://git.rtems.org/chrisj/rtems-deployment.git/. I would like it to be the landing place for this type of stuff if it fits. The repo is being actively worked on by me. I have seen that repo after you mentioned it recently, but I have to admit I haven't looked at it yet. From the name I have guessed that it is more for building release versions and not for continuous checks. I'll take a more detailed look. I can build RPMs on Rocky 8 and 9. These RPMs are the base for EPICS RPMs built into docker containers used to build Gemini's EPICS based systems. All handled via CI in gitlab. That's quite interesting. Do you have a public GitLab instance where you build these or is that a private instance? The rtems-deployment repo doesn't have a .gitlab-ci.yml. Did you keep that separate? Best regards Christian To build an RPM you configure with the path to the RSB and then run `./waf rpmspec`. A spec file is created you can use with `rpmbuild` to make an RPM. I am keeping the generation and building of the RPM separate. By default the repo builds a tarfile. Once this repo stabilises I would like to see if it can move to the top level. I am working on better documentation for it and with that some constraints about what is offered. Deployment is something varies and I hope this repo can grow to make common solutions widely available. I am fine for organisation to send in specific configurations if they are open to having them in the repo. Chris -- 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
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 07:37 schrieb Chris Johns: On 30/9/2022 3:33 pm, Christian MAUDERER wrote: Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. Same. Testing a fix but it takes time to check properly. I am wondering if I can create a test mode in the deployment repo. The hard part is how to automatically check the build has worked. Chris I'm currently trying to create a basic CI/CD setup for testing our embedded brains patches using GitHub. At the moment it's still quite experimental and still a bit thrown together but it basically runs: https://github.com/embedded-brains/rtems-source-builder/actions/runs/3151126889 It didn't catch that bug because it doesn't use installed tools for the simulator runs, but maybe I can change that. If it works well enough, we maybe could re-use some scripts or work flows to set up an official RTEMS CI/CD with whatever community preferred CI system. It shouldn't be too big of a problem to port the logic to Gitlab CI, Cirrus CI or any other modern CI system. 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 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
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Am 30.09.22 um 05:49 schrieb Chris Johns: On 29/9/2022 9:50 pm, Chris Johns wrote: On 29/9/22 9:45 pm, Christian MAUDERER wrote: Hello Chris, thanks for the quick patch. With this qemu and microblaze work again like expected. I tested all tools starting with devel/* and from the ones that work only devel/autotools-internal didn't generate a tar archive. But that one has a comment "Do not use via the command line" in the bset file so that is most likely fine. Some of other devel/* packages didn't build in my test setup, but I have never tested or used them before so that is probably a problem of my build environment or maybe a known bug. Thanks for the testing. I will push to the devel branch and 5. Tarfile creation is working however installing is not. I am working on fixing this. Chris Sorry that I missed that. I only tried to generate the tar archives. 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 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
Re: [PATCH] sb/set-builder: Fix staging and tar file generation with a single config build
Hello Chris,
thanks for the quick patch. With this qemu and microblaze work again
like expected.
I tested all tools starting with devel/* and from the ones that work
only devel/autotools-internal didn't generate a tar archive. But that
one has a comment "Do not use via the command line" in the bset file so
that is most likely fine.
Some of other devel/* packages didn't build in my test setup, but I have
never tested or used them before so that is probably a problem of my
build environment or maybe a known bug.
Best regards
Christian
Am 29.09.22 um 10:52 schrieb chr...@rtems.org:
From: Chris Johns
Closes #4730
---
source-builder/sb/setbuilder.py | 22 ++
1 file changed, 6 insertions(+), 16 deletions(-)
diff --git a/source-builder/sb/setbuilder.py b/source-builder/sb/setbuilder.py
index 3e16111..5921eed 100644
--- a/source-builder/sb/setbuilder.py
+++ b/source-builder/sb/setbuilder.py
@@ -433,19 +433,11 @@ class buildset:
interrupted = False
#
-# If this is the outter most buildset it's files are installed. Nested
-# build sets staged their installed file. The staged files are install
-# when the outtter most build finishes.
+# If installing switch to staging. Not sure if this is still
+# needed.
#
-if nesting_count != 1:
-if self.installing():
-self.macros['install_mode'] = 'staging'
-
-#
-# Only the outter build set can have staging to install. Get the
staging
-# root via the config because it could require a valid config.
-#
-have_staging = False
+if self.installing():
+self.macros['install_mode'] = 'staging'
try:
configs = self.load()
@@ -453,7 +445,7 @@ class buildset:
log.trace('_bset: %2d: %s: configs: %s' % (nesting_count,
self.bset, ',
'.join(configs)))
-if nesting_count == 1 and len(configs) > 1:
+if nesting_count == 1:
#
# Prepend staging areas, bin directory to the
# path. Lets the later package depend on the earlier
@@ -485,8 +477,6 @@ class buildset:
'=' * (74 -
len(configs[s]
bs = buildset(configs[s], self.configs, opts, macros)
bs.build(deps, nesting_count, mail)
-if self.installing():
-have_staging = True
del bs
elif configs[s].endswith('.cfg'):
if mail:
@@ -620,7 +610,7 @@ class buildset:
#
# If builds have been staged install into the final prefix.
#
-if have_staging and not have_errors:
+if not have_errors:
stagingroot = macro_expand(self.macros, '%{stagingroot}')
have_stagingroot = path.exists(stagingroot)
do_install = not self.opts.no_install()
--
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
Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files
Am 29.09.22 um 09:52 schrieb Chris Johns:
On 29/9/22 5:13 pm, Christian MAUDERER wrote:
Am 29.09.22 um 08:56 schrieb Chris Johns:
On 29/9/2022 4:55 pm, Christian MAUDERER wrote:
Am 29.09.22 um 08:54 schrieb Chris Johns:
On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a
ticket?
The tool builds work except for the 6/rtems-microblaze.
Thanks, I will take a look.
I just checked it: There is the same behavior for devel/dtc (which is much
faster to build). Without the patch an archive is created. With the patch it
doesn't create one.
Awesome, that will help.
In case of dtc, it seems to not work because dtc is in
devel/dtc-1.6.1-1.cfg
which ends in a ".cfg" and not in a ".bset".
The bset_tar(...) function is only called if the have_staging is set here:
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n623
That variable seems to be only set to True here:
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n489
And that statement is in a
if configs[s].endswith('.bset')
Does that mean that only bsets can be packed?
It means the build is not being staged and so no bset tar generation. At a guess
a single package in a build does not need to be staged so that step is missed.
Just a bug. If you could please raise a ticket and assign to me I will take care
of this.
https://devel.rtems.org/ticket/4730#ticket
Is there anything I can help with solving that?
Best regards
Christian
Nice work getting it down to here. I appreciate it. >
I think having a tarball for tools like qemu or dtc could be quite useful too.
Agreed.
PS: Not sure yet why microblaze is affected too. That maybe is another case.
Thanks. Getting to it with rtems-deployment repo but I hit 5 verses devel branch
issues.
Chris
--
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
Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files
Am 29.09.22 um 08:56 schrieb Chris Johns:
On 29/9/2022 4:55 pm, Christian MAUDERER wrote:
Am 29.09.22 um 08:54 schrieb Chris Johns:
On 29/9/2022 4:42 pm, Christian MAUDERER wrote:
It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a
ticket?
The tool builds work except for the 6/rtems-microblaze.
Thanks, I will take a look.
I just checked it: There is the same behavior for devel/dtc (which is much
faster to build). Without the patch an archive is created. With the patch it
doesn't create one.
Awesome, that will help.
In case of dtc, it seems to not work because dtc is in
devel/dtc-1.6.1-1.cfg
which ends in a ".cfg" and not in a ".bset".
The bset_tar(...) function is only called if the have_staging is set here:
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n623
That variable seems to be only set to True here:
https://git.rtems.org/rtems-source-builder/tree/source-builder/sb/setbuilder.py?id=161b7f108c3daa0f71ac289ba048a68b730d422c#n489
And that statement is in a
if configs[s].endswith('.bset')
Does that mean that only bsets can be packed? I think having a tarball
for tools like qemu or dtc could be quite useful too.
PS: Not sure yet why microblaze is affected too. That maybe is another case.
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
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
Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files
Am 29.09.22 um 08:54 schrieb Chris Johns: On 29/9/2022 4:42 pm, Christian MAUDERER wrote: It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a ticket? The tool builds work except for the 6/rtems-microblaze. Thanks, I will take a look. I just checked it: There is the same behavior for devel/dtc (which is much faster to build). Without the patch an archive is created. With the patch it doesn't create one. 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 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
Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files
Hello Chris, thanks for the response. Am 29.09.22 um 01:40 schrieb Chris Johns: On 28/9/2022 11:42 pm, Christian MAUDERER wrote: Hello, with this patch, I don't get a tar for devel/qemu and for the 6/rtems-microblaze anymore. All other 6/rtems-* toolchains work without problems. I haven't tested a lot of the other packages. The bset for microblaze is a bit different from the other ones. But I'm not yet sure what the relevant difference is. @Chris: With your change: What is necessary that a bset can generate a tar archive? It could be a bug if the tools builds work, ie 6/rtems-*. Please raise a ticket? The tool builds work except for the 6/rtems-microblaze. I changed the --bset-tar-file option to create a single tarfile of the final staged output of a build. There were a few commits to get this right so I assume you are testing on the latest? I used the current master during the tests. I reverted only the single "Correctly create build set tar files" commit to check whether it was the relevant one. Without this single commit but all others still in place the qemu tar file is created. Incremental tarfiles based on separate buildsets in a buildset may have worked in some cases however there were some basic issues in how it was implemented. When you add deployment requirements on top it did not match up well and it was confusing. The best solution was to rebase the tarfile against the final staged output as that is known to be correct in all cases. I'm not sure whether I understand that, but that is because I never analyzed how the source builder generates the tar files. I'll try to read a bit more documentation and sources. Best regards Christian I have created a https://git.rtems.org/chrisj/rtems-deployment.git repo and in it a config test directory (https://git.rtems.org/chrisj/rtems-deployment.git/tree/config/test). I will look at adding a test to make sure we catch any issues. Thanks Chris -- 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
Re: [rtems-source-builder commit] sb/setbuilder: Correctly create build set tar files
if s == len(configs) - 1 and not have_errors:
-self.bset_tar(b)
else:
deps += b.config.includes()
builds += [b]
@@ -540,7 +551,7 @@ class buildset:
log.trace('_bset: %2d: %s: builds: %s' % \
(nesting_count, self.install_mode(),
', '.join([b.name() for b in builds])))
-if deps is None and not self.opts.no_install() and not have_errors:
+if deps is None and not have_errors:
for b in builds:
log.trace('_bset: : %s: %r' % (self.install_mode(),
b.installable()))
@@ -550,7 +561,6 @@ class buildset:
if self.staging():
prefix = b.config.expand('%{stagingroot}')
self.install(self.install_mode(), b.name(),
buildroot, prefix)
-
#
# Sizes ...
#
@@ -604,16 +614,20 @@ class buildset:
del b
#
-# If builds have been staged install into the finaly prefix.
+# If builds have been staged install into the final prefix.
#
-if have_staging and not self.opts.no_install() and not have_errors:
+if have_staging and not have_errors:
stagingroot = macro_expand(self.macros, '%{stagingroot}')
have_stagingroot = path.exists(stagingroot)
-log.trace('_bset: %2d: install staging, present: %s' % \
- (nesting_count, have_stagingroot))
+do_install = not self.opts.no_install()
+if do_install:
+log.trace('_bset: %2d: install staging, present: %s' % \
+ (nesting_count, have_stagingroot))
if have_stagingroot:
prefix = macro_expand(self.macros, '%{_prefix}')
-self.install(self.install_mode(), self.bset, stagingroot,
prefix)
+if do_install:
+self.install(self.install_mode(), self.bset,
stagingroot, prefix)
+self.bset_tar(stagingroot)
staging_size = path.get_size(stagingroot)
if not self.opts.no_clean() or self.opts.always_clean():
log.notice('clean staging: %s' % (self.bset))
___
vc mailing list
v...@rtems.org
http://lists.rtems.org/mailman/listinfo/vc
--
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
Re: [PATCH RTEMS] Add i2c command
ink it can do more. Thanks for adding that new tool. [9:08 AM] kiwichris: Yes if it is going to replace those commands (which I found after I had done this) it must cover what they do. [9:09 AM] kiwichris: It is great being here to discuss this here and sort if out. Way faster So a big thanks [9:09 AM] c-mauderer: Yes. Discord is great for discussions. I'm only missing a public archive. [9:09 AM] kiwichris: Yeap I agree. [9:09 AM] c-mauderer: Should we copy the discussion into a mail and send it as response to the patch? [9:10 AM] kiwichris: Good idea [9:10 AM] c-mauderer: OK. I'll send a mail. -- ---- 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
Re: [PATCH] cpukit/dev/can: Added CAN support
Hello Prashanth, Am 08.08.22 um 15:49 schrieb Prashanth S: Hi Christian, We have Chris Johns and Christian Mauderer on the list. In this case Chris has sent the mail. To avoid confusion, I never use a short form of my name on the list. But it's easy to mix up so don't worry about it. Oops, I apologize. I think I used gmail style quotes that might have added html. I will not use it. Your mail client added both formats: Text and HTML, regardless whether you use formatting or not. For example your response was mixed too. Interesting is that the mail client managed to use classic usenet style for the text format and some odd HTML with colors for HTML. That's an interesting behavior. For mailing lists it's better to send plain-text-only mails (without the additional HTML stuff). If you use the gmail Web-Client, there seems to be an option hidden in some menu for that: https://www.lifewire.com/how-to-send-a-message-in-plain-text-from-gmail-1171963 Best regards Christian Regards Prashanth S On Mon, 8 Aug 2022 at 05:31, Chris Johns <mailto:chr...@rtems.org>> wrote: Hi Could you please configure your email client to not send HTML emails to the list? I am reluctant to enable filtering in mailman and have managed to avoid it so far. Thanks Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
Re: [PATCH v5 1/4] bsps/stm32f4 Include STM32F4 HAL
impler to avoid in the application? bsps/arm/stm32f4/start/bspstart.c | 202 +- bsps/arm/stm32f4/start/bspstart_old.c | 297 + spec/build/bsps/arm/grp.yml | 5 +- spec/build/bsps/arm/stm32f4/grp.yml | 12 +- spec/build/bsps/arm/stm32f4/obj.yml | 220 + spec/build/bsps/arm/stm32f4/optenhal.yml | 16 + spec/build/bsps/arm/stm32f4/opthse.yml | 17 + spec/build/bsps/arm/stm32f4/optusehse.yml | 16 + spec/build/bsps/arm/stm32f4/optvariant.yml | 24 + spec/build/bsps/obj.yml | 1 + Did the HAL files compile completely without change? If yes, it is OK if you add them to the yml file right here. Otherwise I would suggest to make two to three smaller steps: - Add the unchanged files. Don't add them to the build yet so that the commit would still compile without problems. - Add necessary changes. - Add the files to the build. That makes it simpler to find out what you might had to change to make the files compile and port the changes to a newer version. The HAL files compile completely without changes. However, in one file (stm32f4xx.h), I included bspopts.h. I can split it into 2 commits. Would be great if you could split that. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- ---- 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
Re: [PATCH] cpukit/dev/can: Added CAN support
Hello Prashanth,
Am 19.07.22 um 15:09 schrieb Prashanth S:
Hi Christian,
This is to reply to review comments.
first question: You also worked on a driver for beagle DCAN. Did you
already adapt that driver to this API? If yes, it would be usefull to
post that as a patch too so that the direction and the method how it
will be used is more clear.
Yes, Waiting for License confirmation.
If you didn't have to agree to some really odd license, you can post it
as a patch on the list. Make sure to make it _very_ clear that you are
not sure about the license and for what reason. Things like licensing
should be discussed with the community in public so that the discussion
is archived together with the list.
Note that some of my comments might are a bit critical because you add a
general API. I would have a lot less problems if it would be only a
driver specific API. If you add a general API, it has to fit the needs
of not only your current driver but most future drivers too. Changing an
API later is allways tricky.
Ok
Please make sure to stic to the RTEMS style and use a 80 character line
length.
OK
You create a name with a "'0' + init++": Are you sure that a maximum of
10 buffers are created? Otherwise you will get names like "can:", "can;"
and - sooner or later: "can\xFF", "can\x00", ...
Assuming we have less than 10 CAN controllers, I will update this to
limit to 10 queues.
In the header you somewhere had a "destroy" function. Do you need some
way to de-initialize buffers only used by that bus?
Yes, the can_bus structure holds data related only to a specific bus.
In that case the static variable will make trouble. You have a static
counter. If I register the bus, deregister it and register it again, the
counter will have odd values.
+}
+
+rtems_status_code can_create_tx_buffers(struct can_bus *bus)
+{
+ if ((bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
sizeof(struct can_msg))) == NULL) {
You seem to like writing a lot of code in one line. From my point of
view that makes code harder to read. If you write it into multiple lines
instead, someone else doesn't have to think that much about which
bracket closes where. For example in this case the following would be
simpler to read:
I will make changes to limit line length to 80.
bus->tx_fifo.pbuf = (struct can_msg *)malloc(CAN_TX_BUF_COUNT *
sizeof(struct can_msg));
if (bus->tx_fifo.pbuf == NULL) {
}
+ printf("malloc failed\n");
Prints are nice for debugging but can be really annoying in
applications. Think about some kind of "debug_print" or similar that you
can enable / disable with a macro at the start of the file. You can also
use that to add a prefix or function name to all prints. If you search a
problem, a line like "mallof failed" is meaningless if you are not
currently working on specially this code. A line like
"can_create_tx_buffers: malloc failed" is a lot more usefull. There are
preprocessor macros like __FUNCTION__ that you can use for something
like that.
Ok, I will update the prints with the function name in it.
Better: Use some macro to automate that and enable or disable all debug
messages at once. Also it's not the nicest solution, it's not uncommon
to have something like that. Examples are:
cpukit/libdrvmgr/drvmgr.c:44:#define DBG(x...) printk(x)
cpukit/include/rtems/posix/aio_misc.h:116:#define AIO_printf(_x) printf(_x)
cpukit/libfs/src/ftpfs/ftpfs.c:61: #define DEBUG_PRINTF(...)
printf(__VA_ARGS__)
bsps/mips/malta/pci/pci.c:49: #define JPRINTK(fmt, ...) printk("%s: "
fmt, __FUNCTION__, ##__VA_ARGS__)
+ return RTEMS_NO_MEMORY;
+ }
+
+ bus->tx_fifo.head = bus->tx_fifo.tail = 0;
Same here: This is hard to read. I would suggest to split that into two
lines. Alternatively you might want to think about just using a memset
to have a clean start for a structure that you initialize.
Ok, memset is done in the can_bus_init or calloc is used in
can_bus_alloc_and_init.
Removing bus->tx_fifo.head = bus->tx_fifo.tail = 0;
+ bus->tx_fifo.empty_count = CAN_TX_BUF_COUNT;
+
+ return 0;
+}
+
+bool can_tx_buf_isempty(struct can_bus *bus)
+{
+ if (bus->tx_fifo.empty_count <= 0) {
+ /* tx_fifo.empty_count does not go below zero, incase if it goes update to
zero */
+ bus->tx_fifo.empty_count = 0;
empty_count is an unsigned type and therefore can never be smaller than
0. This line is not necessary at all.
Ok, removing it.
+
+ return false;
+ }
+
+ return true;
+}
+
+struct can_msg *can_tx_get_data_buf(struct can_bus *bus)
+{
+ struct can_msg *msg = NULL;
+
+ if (bus->tx_fifo.empty_count == CAN_TX_BUF_COUNT) {
+ printf("can_tx_get_next_data_buf All buffers are empty\n");
+ return NULL;
+ }
+
+ msg = >tx_fifo.pbuf[bus->tx_fifo.tail];
+ bus->tx_fifo.empty_count++;
+ bus->tx_fifo.tail = (bus->tx_fifo.tail + 1) % CAN_TX_BUF_COUNT;
You want to return the pointer to the message (msg) to the caller,
right? In
Re: Time to promote lwip git repo
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. 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
Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP
Hello Duc,
Am 27.06.22 um 12:39 schrieb Duc Doan:
Hello Christian and Karel,
On Mon, 2022-06-27 at 08:29 +0200, Christian MAUDERER wrote:
Please think about whether you want to start at 0 or at 1!
I want it to start at 0.
Be really careful with that syntax. If you use increasing numbers
like
you suggested, every controller would have to know it's own offest.
On
the other hand, if there is a unique number to each pin, you don't
necessarily need the "ctrl" pointer at all. You can just use
something like
rtems_gpio_write(60, RTEMS_GPIO_PIN_SET);
That's an advantage from the usage perspective because you don't have
to
fetch the GPIO controller and can work with a single pin number.
Disadvantage is a overhead in the API: You have to create some global
table with GPIO controllers and their first and last pins. That table
has to be searched for every operation. In the worst case it adds a
loop
over the table with one comparison for each entry. Most systems
should
only have a hand full of GPIO controller so it's not too much but
it's a
lot more than just one pointer de-referencing. There could be methods
to
optimize the search so the loop might isn't the best solution. But
every
search is slower than if you already have the pointer.
It's more or less a trade-off. There are good arguments for both
directions. I think I have seen both directions implemented in
different
situations.
You are right; having both ctrl and virtual pin number is abundant.
Karel's email gave me some inspiration to (hopefully) improve this:
On Mon, 2022-06-27 at 10:25 +0200, Karel Gardas wrote:
In fact I guess ctrl structure would contain some BSP specific data
and
since bsp_gpio_get_ctrl is BSP specific function for f4 that means in
ctrl you will save your GPIOx and pin number -- e.g. hardware
specific
pin representation.
This means on write/read you do not need to map virtual pin ->
physical
pin again, but in fact use physical pin from ctrl and be as fast as
possible.
Actually as of now, my ctrl structure only has pointers to handlers and
GPIOx (F4 only). Pin number was not in there, but I am thinking
including pin number inside that structure might work. The changes I
want to make would be:
- ctrl structure will now include both pointers to handlers and BSP-
specific physical port/pin
struct rtems_gpio_ctrl {
rtems_gpio_handlers_t *handlers;
}
struct stm32f4_gpio_ctrl {
rtems_gpio_ctrl base;
GPIO_TypeDef *GPIOx;
uint32_t pin; //physical
}
- I will create 2 internal tables (based on Christian's suggestion) to
store the last pins of each controller and pointers to the get_ctrl()
functions. For example, if STM32 has 16 pins per port and 4 ports in
total, my table would be:
uint32_t table[MAX_CONTROLLERS] = {16, 32, 48, 64};
These numbers and the controller pointers are added to the tables by
calling a register() function for each controller. BSPs need to
implement an initialize() function. The prototype of initialize() is
provided by the GPIO API. initialize() needs to be called before any
GPIO operation in the application.
If GPIO expanders exist, their drivers need to have similar initialize
functions that call the register().
Currently I can only think of binary search as a faster method than a
for loop. rtems_gpio_get_ctrl(virtual_pin) will search for the correct
controller, call the BSP/driver-specific get_ctrl(), and return the
result.
- Because pin number is now in ctrl, functions only need to provide
pointer to ctrl object.
Below is an example program with a fake STM32 with 4 GPIOs/16 pins
each. Two GPIO expanders (exA, exB) are used.
/** API header ***/
void register(void (*get_ctrl) (uint32_t pin), uint32_t num_pins); //
shared, already implemented
void initialize(void); // to be implemented by BSP
/** stm32f4 gpio.c **/
void rtems_gpio_initialize(void) {
register(stm32f4_get_ctrl, 16); // port A
register(stm32f4_get_ctrl, 16); // port B
register(stm32f4_get_ctrl, 16); // port C
register(stm32f4_get_ctrl, 16); // port D
}
/* application blink.c ***/
// initialization
rtems_gpio_initialize();
exA_initialize(); // registers pins to the table
exB_initialize(); // registers pins to the table
uint32_t led_pin = 60; // just a random number
rtems_gpio_ctrl_t *led_ctrl = rtems_gpio_get_ctrl(60);
rtems_gpio_write(led_ctrl, RTEMS_GPIO_PIN_SET);
I think I misinterpreted the rtems_gpio_ctrl_t in my earlier mail. With
this example it's now much clearer that the rtems_gpio_ctrl_t now
represents a pin (or maybe a pin group) and not a controller any more. I
would suggest to rename it to rtems_gpio_t or rtems_gpio_pin_t to make
that more clear. Otherwise: OK for me.
/* END OF EXAMPLE **/
The only place where the search must be done is now in get_ctrl(), so
read/write operations are still fast. One drawback of this approach
might be the support for pin groups, but currently I have
Re: [PATCH] Proposal for new GPIO API and example implementation for STM32F4 BSP
pping here ensure portability between BSPs/boards. E.g. for stm32f4 you do not select GPIOA group and pin1, but you select group 0 and pin 1 and in f4 BSP this group 0 is mapped to GPIOA and pin 1 is mapped to its pin 1. -- something like that. Karel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
Re: [PATCH rtems] bsps/atsam: Fix type of options (part 2)
Thanks. I pushed it.
Am 13.06.22 um 19:37 schrieb Joel Sherrill:
Fixes build issues I reported. Please push.
--joel
On Mon, Jun 13, 2022 at 2:18 AM Christian Mauderer
<mailto:christian.maude...@embedded-brains.de>> wrote:
The patch "bsps/atsam: Fix type of options" missed to adapt some parts
of the yml. With that a custom value works well. But if no value is set,
configure doesn't fall back to the default value but instead just causes
an error. This patch fixes that.
---
spec/build/bsps/arm/atsam/optconidx.yml | 3 ++-
spec/build/bsps/arm/atsam/optcontype.yml | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/spec/build/bsps/arm/atsam/optconidx.yml
b/spec/build/bsps/arm/atsam/optconidx.yml
index 1c0723c594..d58d75e4aa 100644
--- a/spec/build/bsps/arm/atsam/optconidx.yml
+++ b/spec/build/bsps/arm/atsam/optconidx.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH
(http://www.embedded-brains.de <http://www.embedded-brains.de>)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device index for /dev/console (default 1, e.g. USART1)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_INDEX
type: build
diff --git a/spec/build/bsps/arm/atsam/optcontype.yml
b/spec/build/bsps/arm/atsam/optcontype.yml
index fd0daa8999..6846fed5f2 100644
--- a/spec/build/bsps/arm/atsam/optcontype.yml
+++ b/spec/build/bsps/arm/atsam/optcontype.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH
(http://www.embedded-brains.de <http://www.embedded-brains.de>)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device type for /dev/console, use 0 for USART and 1 for UART
(default USART)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_TYPE
type: build
--
2.35.3
--
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
[PATCH rtems] bsps/atsam: Fix type of options (part 2)
The patch "bsps/atsam: Fix type of options" missed to adapt some parts
of the yml. With that a custom value works well. But if no value is set,
configure doesn't fall back to the default value but instead just causes
an error. This patch fixes that.
---
spec/build/bsps/arm/atsam/optconidx.yml | 3 ++-
spec/build/bsps/arm/atsam/optcontype.yml | 3 ++-
2 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/spec/build/bsps/arm/atsam/optconidx.yml
b/spec/build/bsps/arm/atsam/optconidx.yml
index 1c0723c594..d58d75e4aa 100644
--- a/spec/build/bsps/arm/atsam/optconidx.yml
+++ b/spec/build/bsps/arm/atsam/optconidx.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device index for /dev/console (default 1, e.g. USART1)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_INDEX
type: build
diff --git a/spec/build/bsps/arm/atsam/optcontype.yml
b/spec/build/bsps/arm/atsam/optcontype.yml
index fd0daa8999..6846fed5f2 100644
--- a/spec/build/bsps/arm/atsam/optcontype.yml
+++ b/spec/build/bsps/arm/atsam/optcontype.yml
@@ -1,7 +1,7 @@
SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause
actions:
- get-integer: null
-- define-condition: null
+- define: null
build-type: option
copyrights:
- Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de)
@@ -10,6 +10,7 @@ default-by-variant: []
description: |
device type for /dev/console, use 0 for USART and 1 for UART (default USART)
enabled-by: true
+format: '{}'
links: []
name: ATSAM_CONSOLE_DEVICE_TYPE
type: build
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: Should README's have license statement?
Hello Joel, Am 10.06.22 um 17:42 schrieb Joel Sherrill: Hi I'm back to relicensing for a bit and noticed that it looks like none of the README's in testsuites have a license or copyright statement. Should they? Difficult question and I don't really have an answer for it. Some longer README files most likely should have a license (like the files in libbsd). Others are very short and contain more or less only a comment for a directory (like the testsuites/sptests/README). I'm not sure about these. I can do forensics on the copyright attribution. Should the README's be BSD-2, Creative Commons, or remain like they are with nothing? READMEs have the tendency that they are added to the documentation once they reach a certain size. So if they need a license I think the same license like in rtems-docs would be the best one. Best regards Christian Thanks. --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] user/bsps/arm: Second Ethernet on i.MX
Hello Chris, Am 09.06.22 um 09:20 schrieb Chris Johns: OK push. Thanks. (I am not familiar with these devices so ...) Is the needed device tree fragments easily available to the user? The device tree for the i.MX6 and i.MX7 series are basically just the ones from FreeBSD or Linux. So there are a lot of examples available. With the additional hints that I added with this patch, it should be possible to create one that is working well for a custom board. Best regards Christian Thanks Chris On 9/6/2022 5:03 pm, Christian Mauderer wrote: This adds information how to use a second Ethernet controller on the i.MX BSPs. --- user/bsps/arm/imx.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst index ee98f0b..e2fd7f2 100644 --- a/user/bsps/arm/imx.rst +++ b/user/bsps/arm/imx.rst @@ -174,6 +174,23 @@ config like that: SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus); #include +On chips with two Ethernet controllers, the MDIO lines are shared between the +two controllers for a number of chips variants. This is currently supported with +some restrictions on the initialization order. For this configuration to work, +you have to make sure that the pins are assigned to the Ethernet controller that +is initialized first. The initialization order in `libbsd` depends on the order +of the Ethernet controllers in the device tree. So if (for example) `fec2` is +defined in the device tree sources before `fec1`, make sure that the MDIO lines +are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in the +device tree. + +Note that the clock for the second Ethernet controller is not necessarily +enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the +startup code if the node that is compatible with `fsl,imx6ul-anatop` can be +found in the device tree. If you have trouble with the second Ethernet +controller make sure that the `ENET2_125M_EN` bit in the `CCM_ANALOG_PLL_ENET` +register is set as expected. + MMC/SDCard Driver - -- 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
Re: [PATCH rtems v2] bsps/imx: Enable clock of ETH2
Thanks for the review and the OK to push.
I created a patch for rtems-docs that gives some information about that
(and about how to use the second Ethernet controller) and sent it to the
list.
Am 08.06.22 um 02:49 schrieb Chris Johns:
Does the BSP doco in the User Manual need updating to mention the clock setting
and the required FDT?
This code fails silently and so documentation is fine or I think the user should
be alerted some other way.
Otherwise OK to push :)
Thanks
Chris
On 7/6/2022 11:05 pm, Christian Mauderer wrote:
---
.../include/arm/freescale/imx/imx6ul_ccmreg.h | 152 ++
bsps/arm/imx/start/bspstart.c | 20 +++
spec/build/bsps/arm/imx/bspimx.yml| 1 +
3 files changed, 173 insertions(+)
create mode 100644 bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
new file mode 100644
index 00..e4b597ba32
--- /dev/null
+++ b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH
+ *
+ * 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 IMX6UL_CCMREG_H
+#define IMX6UL_CCMREG_H
+
+#include
+
+typedef struct {
+ uint32_t ccr;
+ uint32_t ccdr;
+ uint32_t csr;
+ uint32_t ccsr;
+ uint32_t cacrr;
+ uint32_t cbcdr;
+ uint32_t cbcmr;
+ uint32_t cscmr1;
+ uint32_t cscmr2;
+ uint32_t cscdr1;
+ uint32_t cs1cdr;
+ uint32_t cs2cdr;
+ uint32_t cdcdr;
+ uint32_t chsccdr;
+ uint32_t cscdr2;
+ uint32_t cscdr3;
+ uint32_t reserved_40[2];
+ uint32_t cdhipr;
+ uint32_t reserved_4c[2];
+ uint32_t clpcr;
+ uint32_t cisr;
+ uint32_t cimr;
+ uint32_t ccosr;
+ uint32_t cgpr;
+ uint32_t ccgr0;
+ uint32_t ccgr1;
+ uint32_t ccgr2;
+ uint32_t ccgr3;
+ uint32_t ccgr4;
+ uint32_t ccgr5;
+ uint32_t ccgr6;
+ uint32_t reserved_84[1];
+ uint32_t cmeor;
+} imx6ul_ccm;
+
+typedef struct {
+ uint32_t pll_arm;
+ uint32_t pll_arm_set;
+ uint32_t pll_arm_clr;
+ uint32_t pll_arm_tog;
+ uint32_t pll_usb1;
+ uint32_t pll_usb1_set;
+ uint32_t pll_usb1_clr;
+ uint32_t pll_usb1_tog;
+ uint32_t pll_usb2;
+ uint32_t pll_usb2_set;
+ uint32_t pll_usb2_clr;
+ uint32_t pll_usb2_tog;
+ uint32_t pll_sys;
+ uint32_t pll_sys_set;
+ uint32_t pll_sys_clr;
+ uint32_t pll_sys_tog;
+ uint32_t pll_sys_ss;
+ uint32_t reserved_44[3];
+ uint32_t pll_sys_num;
+ uint32_t reserved_54[3];
+ uint32_t pll_sys_denom;
+ uint32_t reserved_64[3];
+ uint32_t pll_audio;
+ uint32_t pll_audio_set;
+ uint32_t pll_audio_clr;
+ uint32_t pll_audio_tog;
+ uint32_t pll_audio_num;
+ uint32_t reserved_84[3];
+ uint32_t pll_audio_denom;
+ uint32_t reserved_94[3];
+ uint32_t pll_video;
+ uint32_t pll_video_set;
+ uint32_t pll_video_clr;
+ uint32_t pll_video_tog;
+ uint32_t pll_video_num;
+ uint32_t reserved_b4[3];
+ uint32_t pll_video_denom;
+ uint32_t reserved_c4[7];
+ uint32_t pll_enet;
+#define IMX6UL_CCM_ANALOG_PLL_ENET_LOCK BSP_BIT32(31)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET_25M_REF_EN BSP_BIT32(21)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET2_125M_EN BSP_BIT32(20)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENABLE_125M BSP_BIT32(19)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_PFD_OFFSET_EN BS
[PATCH] user/bsps/arm: Second Ethernet on i.MX
This adds information how to use a second Ethernet controller on the i.MX BSPs. --- user/bsps/arm/imx.rst | 17 + 1 file changed, 17 insertions(+) diff --git a/user/bsps/arm/imx.rst b/user/bsps/arm/imx.rst index ee98f0b..e2fd7f2 100644 --- a/user/bsps/arm/imx.rst +++ b/user/bsps/arm/imx.rst @@ -174,6 +174,23 @@ config like that: SYSINIT_DRIVER_REFERENCE(ksz8091rnb, miibus); #include +On chips with two Ethernet controllers, the MDIO lines are shared between the +two controllers for a number of chips variants. This is currently supported with +some restrictions on the initialization order. For this configuration to work, +you have to make sure that the pins are assigned to the Ethernet controller that +is initialized first. The initialization order in `libbsd` depends on the order +of the Ethernet controllers in the device tree. So if (for example) `fec2` is +defined in the device tree sources before `fec1`, make sure that the MDIO lines +are routed to `fec2` and that the Ethernet PHYs are a sub-node of `fec2` in the +device tree. + +Note that the clock for the second Ethernet controller is not necessarily +enabled in the `CCM`. On the i.MX6UL/ULL, the clock will be enabled by the +startup code if the node that is compatible with `fsl,imx6ul-anatop` can be +found in the device tree. If you have trouble with the second Ethernet +controller make sure that the `ENET2_125M_EN` bit in the `CCM_ANALOG_PLL_ENET` +register is set as expected. + MMC/SDCard Driver - -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems v2] bsps/imx: Enable clock of ETH2
---
.../include/arm/freescale/imx/imx6ul_ccmreg.h | 152 ++
bsps/arm/imx/start/bspstart.c | 20 +++
spec/build/bsps/arm/imx/bspimx.yml| 1 +
3 files changed, 173 insertions(+)
create mode 100644 bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
diff --git a/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
new file mode 100644
index 00..e4b597ba32
--- /dev/null
+++ b/bsps/arm/imx/include/arm/freescale/imx/imx6ul_ccmreg.h
@@ -0,0 +1,152 @@
+/* SPDX-License-Identifier: BSD-2-Clause */
+
+/*
+ * Copyright (C) 2022 embedded brains GmbH
+ *
+ * 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 IMX6UL_CCMREG_H
+#define IMX6UL_CCMREG_H
+
+#include
+
+typedef struct {
+ uint32_t ccr;
+ uint32_t ccdr;
+ uint32_t csr;
+ uint32_t ccsr;
+ uint32_t cacrr;
+ uint32_t cbcdr;
+ uint32_t cbcmr;
+ uint32_t cscmr1;
+ uint32_t cscmr2;
+ uint32_t cscdr1;
+ uint32_t cs1cdr;
+ uint32_t cs2cdr;
+ uint32_t cdcdr;
+ uint32_t chsccdr;
+ uint32_t cscdr2;
+ uint32_t cscdr3;
+ uint32_t reserved_40[2];
+ uint32_t cdhipr;
+ uint32_t reserved_4c[2];
+ uint32_t clpcr;
+ uint32_t cisr;
+ uint32_t cimr;
+ uint32_t ccosr;
+ uint32_t cgpr;
+ uint32_t ccgr0;
+ uint32_t ccgr1;
+ uint32_t ccgr2;
+ uint32_t ccgr3;
+ uint32_t ccgr4;
+ uint32_t ccgr5;
+ uint32_t ccgr6;
+ uint32_t reserved_84[1];
+ uint32_t cmeor;
+} imx6ul_ccm;
+
+typedef struct {
+ uint32_t pll_arm;
+ uint32_t pll_arm_set;
+ uint32_t pll_arm_clr;
+ uint32_t pll_arm_tog;
+ uint32_t pll_usb1;
+ uint32_t pll_usb1_set;
+ uint32_t pll_usb1_clr;
+ uint32_t pll_usb1_tog;
+ uint32_t pll_usb2;
+ uint32_t pll_usb2_set;
+ uint32_t pll_usb2_clr;
+ uint32_t pll_usb2_tog;
+ uint32_t pll_sys;
+ uint32_t pll_sys_set;
+ uint32_t pll_sys_clr;
+ uint32_t pll_sys_tog;
+ uint32_t pll_sys_ss;
+ uint32_t reserved_44[3];
+ uint32_t pll_sys_num;
+ uint32_t reserved_54[3];
+ uint32_t pll_sys_denom;
+ uint32_t reserved_64[3];
+ uint32_t pll_audio;
+ uint32_t pll_audio_set;
+ uint32_t pll_audio_clr;
+ uint32_t pll_audio_tog;
+ uint32_t pll_audio_num;
+ uint32_t reserved_84[3];
+ uint32_t pll_audio_denom;
+ uint32_t reserved_94[3];
+ uint32_t pll_video;
+ uint32_t pll_video_set;
+ uint32_t pll_video_clr;
+ uint32_t pll_video_tog;
+ uint32_t pll_video_num;
+ uint32_t reserved_b4[3];
+ uint32_t pll_video_denom;
+ uint32_t reserved_c4[7];
+ uint32_t pll_enet;
+#define IMX6UL_CCM_ANALOG_PLL_ENET_LOCK BSP_BIT32(31)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET_25M_REF_EN BSP_BIT32(21)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET2_125M_EN BSP_BIT32(20)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENABLE_125M BSP_BIT32(19)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_PFD_OFFSET_EN BSP_BIT32(18)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_BYPASS BSP_BIT32(16)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_BYPASS_CLK_SRC(val) BSP_FLD32(val, 14, 15)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_BYPASS_CLK_SRC_GET(val) BSP_FLD32GET(val,
14, 15)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_BYPASS_CLK_SRC_SET(val) BSP_FLD32SET(val,
14, 15)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET1_125M_EN BSP_BIT32(13)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_POWERDOWN BSP_BIT32(12)
+#define IMX6UL_CCM_ANALOG_PLL_ENET_ENET1_DIV_SELECT(val) BSP_FLD32(val, 3, 2)
+#define
Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size
Am 02.06.22 um 16:19 schrieb Joel Sherrill:
On Thu, Jun 2, 2022 at 8:58 AM Christian MAUDERER
<mailto:christian.maude...@embedded-brains.de>> wrote:
Am 02.06.22 um 15:49 schrieb Gedare Bloom:
> On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
> mailto:sebastian.hu...@embedded-brains.de>> wrote:
>>
>> On 02/06/2022 09:27, Christian MAUDERER wrote:
>>>
>>> Am 01.06.22 um 14:46 schrieb Gedare Bloom:
>>>> On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
>>>> mailto:christian.maude...@embedded-brains.de>> wrote:
>>>>>
>>>>> Typical embedded systems don't have that much memory. Reduce
the buffer
>>>>> size to something more sensible for the usual type of
application.
>>>>> ---
>>>>> freebsd/sys/dev/ffec/if_ffec.c | 8
>>>>> 1 file changed, 8 insertions(+)
>>>>>
>>>>> diff --git a/freebsd/sys/dev/ffec/if_ffec.c
>>>>> b/freebsd/sys/dev/ffec/if_ffec.c
>>>>> index 47c0f770..4c1e147b 100644
>>>>> --- a/freebsd/sys/dev/ffec/if_ffec.c
>>>>> +++ b/freebsd/sys/dev/ffec/if_ffec.c
>>>>> @@ -139,9 +139,17 @@ static struct ofw_compat_data
compat_data[] = {
>>>>> /*
>>>>> * Driver data and defines. The descriptor counts must be
a power
>>>>> of two.
>>>>> */
>>>>> +#ifndef __rtems__
>>>>> #define RX_DESC_COUNT 512
>>>>> +#else /* __rtems__ */
>>>>> +#define RX_DESC_COUNT 64
>>>>> +#endif /* __rtems__ */
>>>>
>>>> Do we need some way to control this parameter? Or, how will this
>>>> appear if it breaks something?
>>>
>>> I don't expect that there will be any problems. But I can take
a look
>>> how I can make that a parameter.
>>
>> Can we please keep this a compile time constant as it is. The 64
>> descriptors should be more than enough.
>>
> I don't mind the reduction of the constant, but it would be good to
> predict what behavior might indicate this was exceeded. I guess it
> should be some kind of errno on an allocation request though? So it
> should be fine, but if a user hits this limit, I guess they have
> pretty limited options to overcome it.
Reducing the limit won't cause errors. It will only means that if you
flood the target with network packets, it will cache less packets and
start dropping them earlier. That means:
On a short packet burst, some packets will be dropped and (for TCP)
some
have to be re-transmitted. So for short bursts it can be a slight
disadvantage.
On a constant overload situation: It doesn't really make a difference
because the target wouldn't be able to process the packages anyway. It
might even is an advantage because the processor doesn't have to
process
packets that are already outdated and maybe re-transmitted.
How much RAM does this save versus having control over the size of
UDP and TCP RX/TX buffers like we had in the legacy stack? I recall
being able to control the various buffer sizes saved a LOT of memory
on applications I used these parameters on.
There we had four configuration values. Any chance this has a hint
in FreeBSD now or we can provide the same tuning?
rtems_set_udp_buffer_sizes(
rtems_bsdnet_config.udp_tx_buf_size,
rtems_bsdnet_config.udp_rx_buf_size
);
rtems_set_tcp_buffer_sizes(
rtems_bsdnet_config.tcp_tx_buf_size,
rtems_bsdnet_config.tcp_rx_buf_size
);
Are you sure that this is the same buffer? The parameter in this patch
is a driver specific ring buffer of rx descriptors. The parameter that
you mention sounds more like a general network stack buffer (although I
have to say that I don't know these functions of the old stack).
Regarding the sizes:
The driver allocates one mbuf for each buffer. It's a bit tricky to tell
exactly how big one MBUF is. FreeBSD does a lot of abstraction there.
But a debugger tells me that after the initialization one buffer is:
sc->rxbuf_map[0].mbuf->m_len = 2048
That means that I reduced the buffers that are cached in the driver for
sending data from 512 * 2kiB = 1MiB to 64 * 2kiB = 128kiB for the
receive direction. Note that our default size for all mbufs in the stack
is 8MiB (RTEMS_BSD_ALLOCATOR_DOMAIN_PAGE_MBUF_DEFAULT). So 1MiB is a
relevant part of that. And that's only for
Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size
Am 02.06.22 um 15:49 schrieb Gedare Bloom:
On Thu, Jun 2, 2022 at 2:28 AM Sebastian Huber
wrote:
On 02/06/2022 09:27, Christian MAUDERER wrote:
Am 01.06.22 um 14:46 schrieb Gedare Bloom:
On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
wrote:
Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
freebsd/sys/dev/ffec/if_ffec.c | 8
1 file changed, 8 insertions(+)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c
b/freebsd/sys/dev/ffec/if_ffec.c
index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
/*
* Driver data and defines. The descriptor counts must be a power
of two.
*/
+#ifndef __rtems__
#defineRX_DESC_COUNT 512
+#else /* __rtems__ */
+#defineRX_DESC_COUNT 64
+#endif /* __rtems__ */
Do we need some way to control this parameter? Or, how will this
appear if it breaks something?
I don't expect that there will be any problems. But I can take a look
how I can make that a parameter.
Can we please keep this a compile time constant as it is. The 64
descriptors should be more than enough.
I don't mind the reduction of the constant, but it would be good to
predict what behavior might indicate this was exceeded. I guess it
should be some kind of errno on an allocation request though? So it
should be fine, but if a user hits this limit, I guess they have
pretty limited options to overcome it.
Reducing the limit won't cause errors. It will only means that if you
flood the target with network packets, it will cache less packets and
start dropping them earlier. That means:
On a short packet burst, some packets will be dropped and (for TCP) some
have to be re-transmitted. So for short bursts it can be a slight
disadvantage.
On a constant overload situation: It doesn't really make a difference
because the target wouldn't be able to process the packages anyway. It
might even is an advantage because the processor doesn't have to process
packets that are already outdated and maybe re-transmitted.
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
Re: [PATCH rtems] bsps/imx: Enable clock of ETH2
Am 01.06.22 um 14:42 schrieb Gedare Bloom:
On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
wrote:
---
bsps/arm/imx/start/bspstart.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
index 04d48d1558..e9cca49200 100644
--- a/bsps/arm/imx/start/bspstart.c
+++ b/bsps/arm/imx/start/bspstart.c
@@ -161,6 +161,18 @@ static void imx_find_gic(const void *fdt)
#endif
}
+static void imx_ccm_enable_eth2_clk(void)
+{
+ const void *fdt = bsp_fdt_get();
+
+ if (imx_is_imx6(fdt)) {
+volatile uint32_t *ccm_pll_enet_set = (void *)0x020c80e4;
Should this magic address be a #define somewhere?
You are right: I was lazy here because it was only a single register and
I thought that it's not that much difference whether I add it as a
single magic address in the code or as a define in a header. But it's a
bit out of style so I'll change it to match the style of other similar
cases.
+const uint32_t ccm_pll_enet_enet2_125m_en = (1 << 20);
+
+*ccm_pll_enet_set = ccm_pll_enet_enet2_125m_en;
+ }
+}
+
void bsp_start(void)
{
imx_find_gic(bsp_fdt_get());
@@ -169,4 +181,5 @@ void bsp_start(void)
bsp_section_nocacheheap_begin,
(uintptr_t) bsp_section_nocacheheap_size
);
+ imx_ccm_enable_eth2_clk();
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
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
Re: [PATCH rtems-libbsd 2/2] if_ffec: Allow PHY that is connected to other FFEC
Am 01.06.22 um 14:50 schrieb Gedare Bloom:
Should this be upstreamed?
I don't think so. The solution is quite device specific and has some
restrictions like the right initialization order (like noted in the
commit description). I don't think that FreeBSD will accept it.
I have seen some discussions on FreeBSD that they think about a more
generic approach. Basically that would make it necessary to split the
MDIO part from the remaining Ethernet controller part and make it a
separate driver. That would most likely make it necessary to change
multiple or all Ethernet drivers. I assume that some-when someone at
FreeBSD will add a solution like that. But till then, I think the
slightly hacked solution that I did with this patch should work well
enough for us.
On Mon, May 23, 2022 at 6:22 AM Christian Mauderer
wrote:
The i.MX6UL (and some others from the i.MX family) have shared MDIO
lines for multiple FFECs. This patch allows to use the MDIO interface
from another Ethernet controller.
Note that you have to make sure that the FFECs are initialized in the
right order. Normally that can be done via FDT.
---
freebsd/sys/dev/ffec/if_ffec.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 4c1e147b..316e077c 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -209,6 +209,11 @@ struct ffec_softc {
int rx_ic_count;/* RW, valid values 0..255 */
int tx_ic_time;
int tx_ic_count;
+#ifdef __rtems__
+
+ device_tmdio_device;
+ struct mtx mdio_mtx;
+#endif /* __rtems__ */
};
static struct resource_spec irq_res_spec[MAX_IRQ_COUNT + 1] = {
@@ -376,6 +381,13 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
int val;
sc = device_get_softc(dev);
+#ifdef __rtems__
+ if (sc->mdio_device) {
+ return (MIIBUS_READREG(sc->mdio_device, phy, reg));
+ }
+
+ mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */
WR4(sc, FEC_IER_REG, FEC_IER_MII);
@@ -386,11 +398,17 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
if (!ffec_miibus_iowait(sc)) {
device_printf(dev, "timeout waiting for mii read\n");
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (-1); /* All-ones is a symptom of bad mdio. */
}
val = RD4(sc, FEC_MMFR_REG) & FEC_MMFR_DATA_MASK;
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (val);
}
@@ -400,6 +418,13 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int
val)
struct ffec_softc *sc;
sc = device_get_softc(dev);
+#ifdef __rtems__
+ if (sc->mdio_device) {
+ return (MIIBUS_WRITEREG(sc->mdio_device, phy, reg, val));
+ }
+
+ mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */
WR4(sc, FEC_IER_REG, FEC_IER_MII);
@@ -411,9 +436,15 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int
val)
if (!ffec_miibus_iowait(sc)) {
device_printf(dev, "timeout waiting for mii write\n");
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (-1);
}
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (0);
}
@@ -1577,6 +1608,9 @@ ffec_detach(device_t dev)
if (sc->mem_res != NULL)
bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
+#ifdef __rtems__
+ mtx_destroy(>mtx);
+#endif /* __rtems__ */
FFEC_LOCK_DESTROY(sc);
return (0);
}
@@ -1726,6 +1760,80 @@ ffec_set_txic(struct ffec_softc *sc)
ffec_set_ic(sc, FEC_TXIC0_REG, sc->tx_ic_count, sc->tx_ic_time);
}
+#ifdef __rtems__
+int
+ffec_get_phy_information(
+ struct ffec_softc *sc,
+ phandle_t node,
+ device_t dev,
+ int *phy_addr
+)
+{
+ phandle_t phy_node;
+ phandle_t parent_node;
+ pcell_t phy_handle, phy_reg;
+ device_t other;
+ phandle_t xref;
+
+ /* Search for the phy-handle and get the address */
+
+ if (OF_getencprop(node, "phy-handle", (void *)_handle,
+ sizeof(phy_handle)) <= 0)
+ return (ENXIO);
+
+ phy_node = OF_node_from_xref(phy_handle);
+
+ if (OF_getencprop(phy_node, "reg", (void *)_reg,
+ sizeof(phy_reg)) <= 0)
+ return (ENXIO);
+
+ *phy_addr = phy_reg;
+
+ /* Detect whether PHY handle is connected to this or another FFEC. */
+ parent_node = phy_node;
+
+ while (parent_node != 0) {
+ if (parent_node == node) {
+ /* PHY is directly connected. T
Re: [PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size
Hello Gedare,
Am 01.06.22 um 14:46 schrieb Gedare Bloom:
On Mon, May 23, 2022 at 6:21 AM Christian Mauderer
wrote:
Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
freebsd/sys/dev/ffec/if_ffec.c | 8
1 file changed, 8 insertions(+)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
/*
* Driver data and defines. The descriptor counts must be a power of two.
*/
+#ifndef __rtems__
#defineRX_DESC_COUNT 512
+#else /* __rtems__ */
+#defineRX_DESC_COUNT 64
+#endif /* __rtems__ */
Do we need some way to control this parameter? Or, how will this
appear if it breaks something?
I don't expect that there will be any problems. But I can take a look
how I can make that a parameter.
Best regards
Christian
#defineRX_DESC_SIZE(sizeof(struct ffec_hwdesc) * RX_DESC_COUNT)
+#ifndef __rtems__
#defineTX_DESC_COUNT 512
+#else /* __rtems__ */
+#defineTX_DESC_COUNT 64
+#endif /* __rtems__ */
#defineTX_DESC_SIZE(sizeof(struct ffec_hwdesc) * TX_DESC_COUNT)
#defineTX_MAX_DMA_SEGS 8
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
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
[PATCH rtems] bsps/imx: Enable clock of ETH2
---
bsps/arm/imx/start/bspstart.c | 13 +
1 file changed, 13 insertions(+)
diff --git a/bsps/arm/imx/start/bspstart.c b/bsps/arm/imx/start/bspstart.c
index 04d48d1558..e9cca49200 100644
--- a/bsps/arm/imx/start/bspstart.c
+++ b/bsps/arm/imx/start/bspstart.c
@@ -161,6 +161,18 @@ static void imx_find_gic(const void *fdt)
#endif
}
+static void imx_ccm_enable_eth2_clk(void)
+{
+ const void *fdt = bsp_fdt_get();
+
+ if (imx_is_imx6(fdt)) {
+volatile uint32_t *ccm_pll_enet_set = (void *)0x020c80e4;
+const uint32_t ccm_pll_enet_enet2_125m_en = (1 << 20);
+
+*ccm_pll_enet_set = ccm_pll_enet_enet2_125m_en;
+ }
+}
+
void bsp_start(void)
{
imx_find_gic(bsp_fdt_get());
@@ -169,4 +181,5 @@ void bsp_start(void)
bsp_section_nocacheheap_begin,
(uintptr_t) bsp_section_nocacheheap_size
);
+ imx_ccm_enable_eth2_clk();
}
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems-libbsd 2/2] if_ffec: Allow PHY that is connected to other FFEC
The i.MX6UL (and some others from the i.MX family) have shared MDIO
lines for multiple FFECs. This patch allows to use the MDIO interface
from another Ethernet controller.
Note that you have to make sure that the FFECs are initialized in the
right order. Normally that can be done via FDT.
---
freebsd/sys/dev/ffec/if_ffec.c | 120 +
1 file changed, 120 insertions(+)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 4c1e147b..316e077c 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -209,6 +209,11 @@ struct ffec_softc {
int rx_ic_count;/* RW, valid values 0..255 */
int tx_ic_time;
int tx_ic_count;
+#ifdef __rtems__
+
+ device_tmdio_device;
+ struct mtx mdio_mtx;
+#endif /* __rtems__ */
};
static struct resource_spec irq_res_spec[MAX_IRQ_COUNT + 1] = {
@@ -376,6 +381,13 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
int val;
sc = device_get_softc(dev);
+#ifdef __rtems__
+ if (sc->mdio_device) {
+ return (MIIBUS_READREG(sc->mdio_device, phy, reg));
+ }
+
+ mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */
WR4(sc, FEC_IER_REG, FEC_IER_MII);
@@ -386,11 +398,17 @@ ffec_miibus_readreg(device_t dev, int phy, int reg)
if (!ffec_miibus_iowait(sc)) {
device_printf(dev, "timeout waiting for mii read\n");
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (-1); /* All-ones is a symptom of bad mdio. */
}
val = RD4(sc, FEC_MMFR_REG) & FEC_MMFR_DATA_MASK;
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (val);
}
@@ -400,6 +418,13 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int
val)
struct ffec_softc *sc;
sc = device_get_softc(dev);
+#ifdef __rtems__
+ if (sc->mdio_device) {
+ return (MIIBUS_WRITEREG(sc->mdio_device, phy, reg, val));
+ }
+
+ mtx_lock(>mdio_mtx);
+#endif /* __rtems__ */
WR4(sc, FEC_IER_REG, FEC_IER_MII);
@@ -411,9 +436,15 @@ ffec_miibus_writereg(device_t dev, int phy, int reg, int
val)
if (!ffec_miibus_iowait(sc)) {
device_printf(dev, "timeout waiting for mii write\n");
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (-1);
}
+#ifdef __rtems__
+ mtx_unlock(>mdio_mtx);
+#endif /* __rtems__ */
return (0);
}
@@ -1577,6 +1608,9 @@ ffec_detach(device_t dev)
if (sc->mem_res != NULL)
bus_release_resource(dev, SYS_RES_MEMORY, 0, sc->mem_res);
+#ifdef __rtems__
+ mtx_destroy(>mtx);
+#endif /* __rtems__ */
FFEC_LOCK_DESTROY(sc);
return (0);
}
@@ -1726,6 +1760,80 @@ ffec_set_txic(struct ffec_softc *sc)
ffec_set_ic(sc, FEC_TXIC0_REG, sc->tx_ic_count, sc->tx_ic_time);
}
+#ifdef __rtems__
+int
+ffec_get_phy_information(
+ struct ffec_softc *sc,
+ phandle_t node,
+ device_t dev,
+ int *phy_addr
+)
+{
+ phandle_t phy_node;
+ phandle_t parent_node;
+ pcell_t phy_handle, phy_reg;
+ device_t other;
+ phandle_t xref;
+
+ /* Search for the phy-handle and get the address */
+
+ if (OF_getencprop(node, "phy-handle", (void *)_handle,
+ sizeof(phy_handle)) <= 0)
+ return (ENXIO);
+
+ phy_node = OF_node_from_xref(phy_handle);
+
+ if (OF_getencprop(phy_node, "reg", (void *)_reg,
+ sizeof(phy_reg)) <= 0)
+ return (ENXIO);
+
+ *phy_addr = phy_reg;
+
+ /* Detect whether PHY handle is connected to this or another FFEC. */
+ parent_node = phy_node;
+
+ while (parent_node != 0) {
+ if (parent_node == node) {
+ /* PHY is directly connected. That's easy. */
+ sc->mdio_device = NULL;
+ return 0;
+ }
+
+ /*
+* Check whether the node is also an Ethernet controller. Do
+* that by just assuming that every Ethernet controller has a
+* PHY attached to it.
+*/
+ if (OF_getencprop(parent_node, "phy-handle",
+ (void *)_handle, sizeof(phy_handle)) > 0) {
+ /*
+* Try to find the device of the other Ethernet
+* controller and use that for MDIO communication.
+* Note: This is not really a nice workaround but it
+* works.
+*/
+ xref = OF_xref_from_node(parent_node);
+ if (xref == 0) {
+ device_printf(dev,
+
[PATCH rtems-libbsd 1/2] if_ffec: Reduce buffer size
Typical embedded systems don't have that much memory. Reduce the buffer
size to something more sensible for the usual type of application.
---
freebsd/sys/dev/ffec/if_ffec.c | 8
1 file changed, 8 insertions(+)
diff --git a/freebsd/sys/dev/ffec/if_ffec.c b/freebsd/sys/dev/ffec/if_ffec.c
index 47c0f770..4c1e147b 100644
--- a/freebsd/sys/dev/ffec/if_ffec.c
+++ b/freebsd/sys/dev/ffec/if_ffec.c
@@ -139,9 +139,17 @@ static struct ofw_compat_data compat_data[] = {
/*
* Driver data and defines. The descriptor counts must be a power of two.
*/
+#ifndef __rtems__
#defineRX_DESC_COUNT 512
+#else /* __rtems__ */
+#defineRX_DESC_COUNT 64
+#endif /* __rtems__ */
#defineRX_DESC_SIZE(sizeof(struct ffec_hwdesc) * RX_DESC_COUNT)
+#ifndef __rtems__
#defineTX_DESC_COUNT 512
+#else /* __rtems__ */
+#defineTX_DESC_COUNT 64
+#endif /* __rtems__ */
#defineTX_DESC_SIZE(sizeof(struct ffec_hwdesc) * TX_DESC_COUNT)
#defineTX_MAX_DMA_SEGS 8
--
2.35.3
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
[PATCH 0/2] Improve support for second Ethernet on i.MX6UL
Hello, these patches improve the support for the second Ethernet controller on the i.MX6UL (and most likely 7) series. Best regards Christian ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH rtems] bsps/atsam: Fix type of options
ATSAM_CONSOLE_DEVICE_INDEX and ATSAM_CONSOLE_DEVICE_TYPE have to be integers like suggested by their description. Otherwise it's not possible to select (for example) USART2 as console device. --- spec/build/bsps/arm/atsam/optconidx.yml | 4 ++-- spec/build/bsps/arm/atsam/optcontype.yml | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) diff --git a/spec/build/bsps/arm/atsam/optconidx.yml b/spec/build/bsps/arm/atsam/optconidx.yml index 42fb3b142a..1c0723c594 100644 --- a/spec/build/bsps/arm/atsam/optconidx.yml +++ b/spec/build/bsps/arm/atsam/optconidx.yml @@ -1,11 +1,11 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: -- get-boolean: null +- get-integer: null - define-condition: null build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) -default: true +default: 1 default-by-variant: [] description: | device index for /dev/console (default 1, e.g. USART1) diff --git a/spec/build/bsps/arm/atsam/optcontype.yml b/spec/build/bsps/arm/atsam/optcontype.yml index eddbee1063..fd0daa8999 100644 --- a/spec/build/bsps/arm/atsam/optcontype.yml +++ b/spec/build/bsps/arm/atsam/optcontype.yml @@ -1,11 +1,11 @@ SPDX-License-Identifier: CC-BY-SA-4.0 OR BSD-2-Clause actions: -- get-boolean: null +- get-integer: null - define-condition: null build-type: option copyrights: - Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) -default: false +default: 0 default-by-variant: [] description: | device type for /dev/console, use 0 for USART and 1 for UART (default USART) -- 2.35.3 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] imfs: Fix index underrun when extending empty file
Am 04.04.22 um 16:41 schrieb Christian MAUDERER:
Am 04.04.22 um 16:40 schrieb Joel Sherrill:
On Mon, Apr 4, 2022, 9:28 AM Christian MAUDERER
<mailto:christian.maude...@embedded-brains.de>> wrote:
Please note: I would like to apply this to the 5 branch too. I
created a
ticket for 5 here:
https://devel.rtems.org/ticket/4638
<https://devel.rtems.org/ticket/4638>
Note that both tickets (5 and 6) are clones of an old 4.11 ticket:
https://devel.rtems.org/ticket/2353
<https://devel.rtems.org/ticket/2353>
I didn't plan to backport the patch to 4.11. I'll add a comment to
the
ticket that the problem is fixed in 5 and 6. Should I close the 4.11
ticket with a "wontfix" or just let it open?
If the ticket applies easily, just apply it after testing on 5 and 6.
Please.
OK. I'll try it.
I applied the patch to all three branches (master, 5, 4.11). I only
skipped adding the test for 4.11 because that part didn't apply without
problems. But the bug is fixed there too.
Best regards
Christian
Is there a test case for this?
The patch adds one.
--joel
Best regards
Christian
Am 04.04.22 um 16:23 schrieb Christian Mauderer:
> Currently the following sequence causes a endless loop when
extending an
> IMFS file:
>
> - Create a file with zero length and close it.
> - Make sure nearly no allocatable memory is left.
> - Open the file and write enough data into it that more than the
> remaining memory will be used.
>
> In that case when extending the IMFS file, the file currently
need zero
> blocks. If allocating enough new blocks fails, the already
allocated new
> blocks will be freed again.
>
> The comparison of block>=old_blocks that has been used prior to
this
> patch compared two unsigned numbers. If old_blocks was zero, the
> comparison of these two numbers always evaluated to true.
>
> This patch frees the last block in a separate step to avoid this
> problem.
>
> Fixes #4639
> ---
> cpukit/libfs/src/imfs/imfs_memfile.c | 3 ++-
> testsuites/psxtests/psximfs02/init.c | 30
+++-
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libfs/src/imfs/imfs_memfile.c
b/cpukit/libfs/src/imfs/imfs_memfile.c
> index 23c7192717..769a570ecf 100644
> --- a/cpukit/libfs/src/imfs/imfs_memfile.c
> +++ b/cpukit/libfs/src/imfs/imfs_memfile.c
> @@ -208,9 +208,10 @@ static int IMFS_memfile_extend(
> offset = 0;
> }
> } else {
> - for ( ; block>=old_blocks ; block-- ) {
> + for ( ; block>old_blocks ; block-- ) {
> IMFS_memfile_remove_block( memfile, block );
> }
> + IMFS_memfile_remove_block( memfile, old_blocks );
> rtems_set_errno_and_return_minus_one( ENOSPC );
> }
> }
> diff --git a/testsuites/psxtests/psximfs02/init.c
b/testsuites/psxtests/psximfs02/init.c
> index 15b9137121..04f806f565 100644
> --- a/testsuites/psxtests/psximfs02/init.c
> +++ b/testsuites/psxtests/psximfs02/init.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#define MEMFILE_BYTES_PER_BLOCK 16
> +
> const char rtems_test_name[] = "PSXIMFS 2";
>
> /* forward declarations to avoid warnings */
> @@ -43,12 +45,17 @@ rtems_task Init(
> static const uintptr_t slink_2_name_size [] = {
> sizeof( slink_2_name )
> };
> + static const uintptr_t some_blocks [] = {
> + MEMFILE_BYTES_PER_BLOCK * 10
> + };
> + static const char some_data[MEMFILE_BYTES_PER_BLOCK * 11];
>
> int status = 0;
> void *opaque;
> char linkname_n[32] = {0};
> char linkname_p[32] = {0};
> int i;
> + int fd;
> struct stat stat_buf;
>
> TEST_BEGIN();
> @@ -102,6 +109,27 @@ rtems_task Init(
> rtems_test_assert( status == -1 );
> rtems_test_assert( errno == EACCES );
>
> + puts( "Allocate most of heap with a little bit left" );
> + opaque = rtems_heap_greedy_allocate( some_blocks, 1 );
> +
> + puts( "Create an empty file.");
> + status = mknod( "/foo", S_IFREG | S_IRWXU, 0LL );
> + rtems_test_assert( status == 0 );
> +
> + puts( "Then increase it's size to more than remaining space" );
> + fd = open( "/foo", O_WRONLY
Re: [PATCH] imfs: Fix index underrun when extending empty file
Am 04.04.22 um 16:40 schrieb Joel Sherrill:
On Mon, Apr 4, 2022, 9:28 AM Christian MAUDERER
<mailto:christian.maude...@embedded-brains.de>> wrote:
Please note: I would like to apply this to the 5 branch too. I
created a
ticket for 5 here:
https://devel.rtems.org/ticket/4638
<https://devel.rtems.org/ticket/4638>
Note that both tickets (5 and 6) are clones of an old 4.11 ticket:
https://devel.rtems.org/ticket/2353
<https://devel.rtems.org/ticket/2353>
I didn't plan to backport the patch to 4.11. I'll add a comment to the
ticket that the problem is fixed in 5 and 6. Should I close the 4.11
ticket with a "wontfix" or just let it open?
If the ticket applies easily, just apply it after testing on 5 and 6.
Please.
OK. I'll try it.
Is there a test case for this?
The patch adds one.
--joel
Best regards
Christian
Am 04.04.22 um 16:23 schrieb Christian Mauderer:
> Currently the following sequence causes a endless loop when
extending an
> IMFS file:
>
> - Create a file with zero length and close it.
> - Make sure nearly no allocatable memory is left.
> - Open the file and write enough data into it that more than the
> remaining memory will be used.
>
> In that case when extending the IMFS file, the file currently
need zero
> blocks. If allocating enough new blocks fails, the already
allocated new
> blocks will be freed again.
>
> The comparison of block>=old_blocks that has been used prior to this
> patch compared two unsigned numbers. If old_blocks was zero, the
> comparison of these two numbers always evaluated to true.
>
> This patch frees the last block in a separate step to avoid this
> problem.
>
> Fixes #4639
> ---
> cpukit/libfs/src/imfs/imfs_memfile.c | 3 ++-
> testsuites/psxtests/psximfs02/init.c | 30
+++-
> 2 files changed, 31 insertions(+), 2 deletions(-)
>
> diff --git a/cpukit/libfs/src/imfs/imfs_memfile.c
b/cpukit/libfs/src/imfs/imfs_memfile.c
> index 23c7192717..769a570ecf 100644
> --- a/cpukit/libfs/src/imfs/imfs_memfile.c
> +++ b/cpukit/libfs/src/imfs/imfs_memfile.c
> @@ -208,9 +208,10 @@ static int IMFS_memfile_extend(
> offset = 0;
> }
> } else {
> - for ( ; block>=old_blocks ; block-- ) {
> + for ( ; block>old_blocks ; block-- ) {
> IMFS_memfile_remove_block( memfile, block );
> }
> + IMFS_memfile_remove_block( memfile, old_blocks );
> rtems_set_errno_and_return_minus_one( ENOSPC );
> }
> }
> diff --git a/testsuites/psxtests/psximfs02/init.c
b/testsuites/psxtests/psximfs02/init.c
> index 15b9137121..04f806f565 100644
> --- a/testsuites/psxtests/psximfs02/init.c
> +++ b/testsuites/psxtests/psximfs02/init.c
> @@ -23,6 +23,8 @@
> #include
> #include
>
> +#define MEMFILE_BYTES_PER_BLOCK 16
> +
> const char rtems_test_name[] = "PSXIMFS 2";
>
> /* forward declarations to avoid warnings */
> @@ -43,12 +45,17 @@ rtems_task Init(
> static const uintptr_t slink_2_name_size [] = {
> sizeof( slink_2_name )
> };
> + static const uintptr_t some_blocks [] = {
> + MEMFILE_BYTES_PER_BLOCK * 10
> + };
> + static const char some_data[MEMFILE_BYTES_PER_BLOCK * 11];
>
> int status = 0;
> void *opaque;
> char linkname_n[32] = {0};
> char linkname_p[32] = {0};
> int i;
> + int fd;
> struct stat stat_buf;
>
> TEST_BEGIN();
> @@ -102,6 +109,27 @@ rtems_task Init(
> rtems_test_assert( status == -1 );
> rtems_test_assert( errno == EACCES );
>
> + puts( "Allocate most of heap with a little bit left" );
> + opaque = rtems_heap_greedy_allocate( some_blocks, 1 );
> +
> + puts( "Create an empty file.");
> + status = mknod( "/foo", S_IFREG | S_IRWXU, 0LL );
> + rtems_test_assert( status == 0 );
> +
> + puts( "Then increase it's size to more than remaining space" );
> + fd = open( "/foo", O_WRONLY | O_TRUNC);
> + rtems_test_assert( fd >= 0 );
> + status = write(fd, some_data, sizeof(some_data));
> + rtems_test_assert( status == -1);
> + rtems_test_assert( errno == ENOSPC );
> +
> + puts( "Clean up again
Re: [PATCH] imfs: Fix index underrun when extending empty file
Please note: I would like to apply this to the 5 branch too. I created a
ticket for 5 here:
https://devel.rtems.org/ticket/4638
Note that both tickets (5 and 6) are clones of an old 4.11 ticket:
https://devel.rtems.org/ticket/2353
I didn't plan to backport the patch to 4.11. I'll add a comment to the
ticket that the problem is fixed in 5 and 6. Should I close the 4.11
ticket with a "wontfix" or just let it open?
Best regards
Christian
Am 04.04.22 um 16:23 schrieb Christian Mauderer:
Currently the following sequence causes a endless loop when extending an
IMFS file:
- Create a file with zero length and close it.
- Make sure nearly no allocatable memory is left.
- Open the file and write enough data into it that more than the
remaining memory will be used.
In that case when extending the IMFS file, the file currently need zero
blocks. If allocating enough new blocks fails, the already allocated new
blocks will be freed again.
The comparison of block>=old_blocks that has been used prior to this
patch compared two unsigned numbers. If old_blocks was zero, the
comparison of these two numbers always evaluated to true.
This patch frees the last block in a separate step to avoid this
problem.
Fixes #4639
---
cpukit/libfs/src/imfs/imfs_memfile.c | 3 ++-
testsuites/psxtests/psximfs02/init.c | 30 +++-
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/imfs/imfs_memfile.c
b/cpukit/libfs/src/imfs/imfs_memfile.c
index 23c7192717..769a570ecf 100644
--- a/cpukit/libfs/src/imfs/imfs_memfile.c
+++ b/cpukit/libfs/src/imfs/imfs_memfile.c
@@ -208,9 +208,10 @@ static int IMFS_memfile_extend(
offset = 0;
}
} else {
- for ( ; block>=old_blocks ; block-- ) {
+ for ( ; block>old_blocks ; block-- ) {
IMFS_memfile_remove_block( memfile, block );
}
+ IMFS_memfile_remove_block( memfile, old_blocks );
rtems_set_errno_and_return_minus_one( ENOSPC );
}
}
diff --git a/testsuites/psxtests/psximfs02/init.c
b/testsuites/psxtests/psximfs02/init.c
index 15b9137121..04f806f565 100644
--- a/testsuites/psxtests/psximfs02/init.c
+++ b/testsuites/psxtests/psximfs02/init.c
@@ -23,6 +23,8 @@
#include
#include
+#define MEMFILE_BYTES_PER_BLOCK 16
+
const char rtems_test_name[] = "PSXIMFS 2";
/* forward declarations to avoid warnings */
@@ -43,12 +45,17 @@ rtems_task Init(
static const uintptr_t slink_2_name_size [] = {
sizeof( slink_2_name )
};
+ static const uintptr_t some_blocks [] = {
+MEMFILE_BYTES_PER_BLOCK * 10
+ };
+ static const char some_data[MEMFILE_BYTES_PER_BLOCK * 11];
int status = 0;
void *opaque;
char linkname_n[32] = {0};
char linkname_p[32] = {0};
int i;
+ int fd;
struct stat stat_buf;
TEST_BEGIN();
@@ -102,6 +109,27 @@ rtems_task Init(
rtems_test_assert( status == -1 );
rtems_test_assert( errno == EACCES );
+ puts( "Allocate most of heap with a little bit left" );
+ opaque = rtems_heap_greedy_allocate( some_blocks, 1 );
+
+ puts( "Create an empty file.");
+ status = mknod( "/foo", S_IFREG | S_IRWXU, 0LL );
+ rtems_test_assert( status == 0 );
+
+ puts( "Then increase it's size to more than remaining space" );
+ fd = open( "/foo", O_WRONLY | O_TRUNC);
+ rtems_test_assert( fd >= 0 );
+ status = write(fd, some_data, sizeof(some_data));
+ rtems_test_assert( status == -1);
+ rtems_test_assert( errno == ENOSPC );
+
+ puts( "Clean up again" );
+ status = close(fd);
+ rtems_test_assert( status == 0);
+ status = remove( "/foo" );
+ rtems_test_assert( status == 0);
+ rtems_heap_greedy_free( opaque );
+
puts( "Allocate most of heap" );
opaque = rtems_heap_greedy_allocate( mount_table_entry_size, 1 );
@@ -202,7 +230,7 @@ rtems_task Init(
#define CONFIGURE_FILESYSTEM_IMFS
#define CONFIGURE_MAXIMUM_TASKS 1
-#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK 16
+#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK MEMFILE_BYTES_PER_BLOCK
#define CONFIGURE_IMFS_ENABLE_MKFIFO
#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 4
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
--
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
[PATCH] imfs: Fix index underrun when extending empty file
Currently the following sequence causes a endless loop when extending an
IMFS file:
- Create a file with zero length and close it.
- Make sure nearly no allocatable memory is left.
- Open the file and write enough data into it that more than the
remaining memory will be used.
In that case when extending the IMFS file, the file currently need zero
blocks. If allocating enough new blocks fails, the already allocated new
blocks will be freed again.
The comparison of block>=old_blocks that has been used prior to this
patch compared two unsigned numbers. If old_blocks was zero, the
comparison of these two numbers always evaluated to true.
This patch frees the last block in a separate step to avoid this
problem.
Fixes #4639
---
cpukit/libfs/src/imfs/imfs_memfile.c | 3 ++-
testsuites/psxtests/psximfs02/init.c | 30 +++-
2 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/cpukit/libfs/src/imfs/imfs_memfile.c
b/cpukit/libfs/src/imfs/imfs_memfile.c
index 23c7192717..769a570ecf 100644
--- a/cpukit/libfs/src/imfs/imfs_memfile.c
+++ b/cpukit/libfs/src/imfs/imfs_memfile.c
@@ -208,9 +208,10 @@ static int IMFS_memfile_extend(
offset = 0;
}
} else {
- for ( ; block>=old_blocks ; block-- ) {
+ for ( ; block>old_blocks ; block-- ) {
IMFS_memfile_remove_block( memfile, block );
}
+ IMFS_memfile_remove_block( memfile, old_blocks );
rtems_set_errno_and_return_minus_one( ENOSPC );
}
}
diff --git a/testsuites/psxtests/psximfs02/init.c
b/testsuites/psxtests/psximfs02/init.c
index 15b9137121..04f806f565 100644
--- a/testsuites/psxtests/psximfs02/init.c
+++ b/testsuites/psxtests/psximfs02/init.c
@@ -23,6 +23,8 @@
#include
#include
+#define MEMFILE_BYTES_PER_BLOCK 16
+
const char rtems_test_name[] = "PSXIMFS 2";
/* forward declarations to avoid warnings */
@@ -43,12 +45,17 @@ rtems_task Init(
static const uintptr_t slink_2_name_size [] = {
sizeof( slink_2_name )
};
+ static const uintptr_t some_blocks [] = {
+MEMFILE_BYTES_PER_BLOCK * 10
+ };
+ static const char some_data[MEMFILE_BYTES_PER_BLOCK * 11];
int status = 0;
void *opaque;
char linkname_n[32] = {0};
char linkname_p[32] = {0};
int i;
+ int fd;
struct stat stat_buf;
TEST_BEGIN();
@@ -102,6 +109,27 @@ rtems_task Init(
rtems_test_assert( status == -1 );
rtems_test_assert( errno == EACCES );
+ puts( "Allocate most of heap with a little bit left" );
+ opaque = rtems_heap_greedy_allocate( some_blocks, 1 );
+
+ puts( "Create an empty file.");
+ status = mknod( "/foo", S_IFREG | S_IRWXU, 0LL );
+ rtems_test_assert( status == 0 );
+
+ puts( "Then increase it's size to more than remaining space" );
+ fd = open( "/foo", O_WRONLY | O_TRUNC);
+ rtems_test_assert( fd >= 0 );
+ status = write(fd, some_data, sizeof(some_data));
+ rtems_test_assert( status == -1);
+ rtems_test_assert( errno == ENOSPC );
+
+ puts( "Clean up again" );
+ status = close(fd);
+ rtems_test_assert( status == 0);
+ status = remove( "/foo" );
+ rtems_test_assert( status == 0);
+ rtems_heap_greedy_free( opaque );
+
puts( "Allocate most of heap" );
opaque = rtems_heap_greedy_allocate( mount_table_entry_size, 1 );
@@ -202,7 +230,7 @@ rtems_task Init(
#define CONFIGURE_FILESYSTEM_IMFS
#define CONFIGURE_MAXIMUM_TASKS 1
-#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK 16
+#define CONFIGURE_IMFS_MEMFILE_BYTES_PER_BLOCK MEMFILE_BYTES_PER_BLOCK
#define CONFIGURE_IMFS_ENABLE_MKFIFO
#define CONFIGURE_MAXIMUM_FILE_DESCRIPTORS 4
#define CONFIGURE_INITIAL_EXTENSIONS RTEMS_TEST_INITIAL_EXTENSION
--
2.34.1
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH 00/26] Bulk Relicense to BSD-2
/pci_for_each_child.c| 25 +++- cpukit/libpci/pci_for_each_dev.c | 25 +++- cpukit/libpci/pci_get_dev.c | 25 +++- cpukit/libpci/pci_internal.h | 25 +++- cpukit/libpci/pci_irq.c | 25 +++- cpukit/libpci/pci_print.c | 25 +++- cpukit/libtest/testbeginend.c | 25 +++- cpukit/libtest/testbusy.c | 25 +++- cpukit/libtest/testextension.c| 25 +++- cpukit/libtest/testparallel.c | 25 +++- cpukit/libtest/testwrappers.c | 25 +++- 204 files changed, 4702 insertions(+), 860 deletions(-) -- 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
Re: [PATCH 22/26] cpukit/libmisc/redirector: Manually change license to BSD-2
Am 18.03.22 um 17:21 schrieb Joel Sherrill: Updates #3053. --- cpukit/libmisc/redirector/stdio-redirect.c | 33 -- 1 file changed, 25 insertions(+), 8 deletions(-) diff --git a/cpukit/libmisc/redirector/stdio-redirect.c b/cpukit/libmisc/redirector/stdio-redirect.c index 7f3e9138a7..712968ac2d 100644 --- a/cpukit/libmisc/redirector/stdio-redirect.c +++ b/cpukit/libmisc/redirector/stdio-redirect.c @@ -1,16 +1,33 @@ -/* - * Copyright (C) 2014 Chris Johns (chr...@rtems.org) +/** + * @file * - * The license and distribution terms for this file may be - * found in the file LICENSE in this distribution. - * - * This software with is provided ``as is'' and with NO WARRANTY. + * @brief RTEMS std redirector. */ /* - * RTEMS std redirector. + * Copyright (C) 2014 Chris Johns (chr...@rtems.org) + * + * 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. */ - Is removing that line correct? I think most files have one empty line between the license and the first code line. #include #include #include -- 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
Re: [PATCH 14/26] cpukit/libmisc/capture: Manually change license to BSD-2
urement Framework. - - This is the Capture Engine component. -*/ + * Copyright 2002, 2016 Chris Johns . All rights reserved. + * + * COPYRIGHT (c) 1989-2014. + * On-Line Applications Research Corporation (OAR). + * + * 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. + */ #ifdef HAVE_CONFIG_H #include "config.h" -- 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
Re: [PATCH 07/26] cpukit/libds/src/ftpfs/tftpDriver.c: Manually update license to BSD-2
Am 18.03.22 um 17:21 schrieb Joel Sherrill: Eric Norum granted permission plus git log archeology to get year for his copyright. Updates #3053. --- cpukit/libfs/src/ftpfs/tftpDriver.c | 38 +++-- 1 file changed, 30 insertions(+), 8 deletions(-) diff --git a/cpukit/libfs/src/ftpfs/tftpDriver.c b/cpukit/libfs/src/ftpfs/tftpDriver.c index bc0e74ad86..ef8dc33351 100644 --- a/cpukit/libfs/src/ftpfs/tftpDriver.c +++ b/cpukit/libfs/src/ftpfs/tftpDriver.c @@ -1,17 +1,39 @@ -/* - * Trivial File Transfer Protocol (RFC 1350) +/* SPDX-License-Identifier: BSD-2-Clause */ + +/** + * @file * - * Transfer file to/from remote host + * Trivial File Transfer Protocol file system (TFTP client) for RFC 1350. * - * W. Eric Norum - * Saskatchewan Accelerator Laboratory - * University of Saskatchewan - * Saskatoon, Saskatchewan, CANADA - * e...@skatter.usask.ca + * Transfer file to/from remote host + */ + +/* + * Copyright 1998 W. Eric Norum Not entirely sure but in later copyright lines, Eric Norum added his mail address. For example 2002: https://git.rtems.org/rtems/tree/cpukit/libcsupport/src/getgrent.c Shouldn't we prefer that form here too? * * Modifications to support reference counting in the file system are * Copyright (c) 2012 embedded brains GmbH. * + * 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. */ #ifdef HAVE_CONFIG_H -- 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
Re: [PATCH 01/26] cpukit/libdl/rtl-alloc-check.py: Change to BSD-2 by hand
Shouldn't there be a SPDX-line added to this file? Am 18.03.22 um 17:21 schrieb Joel Sherrill: Updates #3053. --- cpukit/libdl/rtl-alloc-check.py | 30 +++--- 1 file changed, 23 insertions(+), 7 deletions(-) diff --git a/cpukit/libdl/rtl-alloc-check.py b/cpukit/libdl/rtl-alloc-check.py index c2145a768e..3d6b024442 100644 --- a/cpukit/libdl/rtl-alloc-check.py +++ b/cpukit/libdl/rtl-alloc-check.py @@ -1,11 +1,4 @@ # -# Copyright (c) 2019 Chris Johns . -# All rights reserved. -# -# 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. -# # Check the allocations for libdl: # # 1. Turn on the allocation trace. @@ -13,7 +6,30 @@ # 2. Load and unload object files. # # 3. Capture the trace output and feed to this tool + +# Copyright (c) 2019 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 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. from __future__ import print_function -- 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
Re: [PATCH 11/40] bsps/include/libchip/disp_hcms29xx.h: Manual file header clean up
Hello Heinz, thanks for reporting and analyzing it. And sorry for pushing a patch that broke it in the first place. I was just looking through the error messages whether there is a second error. I'll push a patch for the closing comment in the next few minutes. Best regards Christian Am 10.03.22 um 14:50 schrieb Heinz Junkes: Only the comment end ( */ ) is missing in bsps/include/libchip/disp_hcms29xx.h at line 14. Viele Grüße Heinz Junkes -- Experience directly varies with equipment ruined. On 10. Mar 2022, at 14:39, Heinz Junkes wrote: I get this at the moment when compiling the kernel: ... [ 48/4243] Compiling bsps/shared/freebsd/sys/arm/ti/am335x/am335x_scm_padconf.c [ 49/4243] Compiling bsps/shared/irq/irq-shell.c [ 50/4243] Compiling bsps/shared/irq/irq-info.c In file included from ../../../bsps/shared/dev/display/disp_hcms29xx.c:24: ../../../bsps/include/libchip/disp_hcms29xx.h:26:40: warning: "/*" within comment [-Wcomment] 26 | rtems_device_minor_number minor; /* minor device number */ devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- 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
Re: [PATCH 01/40] License Header Clean Up
I pushed the patches. Am 07.03.22 um 15:33 schrieb Joel Sherrill: On Mon, Mar 7, 2022 at 7:25 AM Christian Mauderer <mailto:christian.maude...@embedded-brains.de>> wrote: Hello, during the re-license efforts, Joel noted that there are a lot of really odd old headers from people at embedded brains. We joined efforts to clean them up. After this patch series, we should have removed most of these odd headers. To pile on that statement -- there should be NO changes to code -- only file headers. Please don't hesitate to point out any mistakes that I did during the clean up. It was a repetitive task and therefore is definitively prone to errors. I manually cleaned up some files but most of my changes were driven by scripts and also may be subject to mistakes. In case some file doesn't reach the list: I also pushed the patches on a branch on gitlab: https://gitlab.com/c-mauderer/rtems/-/tree/cm/20220302_file_header_clean_up <https://gitlab.com/c-mauderer/rtems/-/tree/cm/20220302_file_header_clean_up> I reviewed this and am ok with pushing it but it would be nice to hear from others. This touched a lot of files. --joel 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
[PATCH 33/40] testsuites: Manual file header clean up
Updates #4625. --- testsuites/libtests/block10/init.c | 6 -- testsuites/sptests/spinternalerror02/init.c | 6 -- 2 files changed, 12 deletions(-) diff --git a/testsuites/libtests/block10/init.c b/testsuites/libtests/block10/init.c index b50c731d6d..d699968975 100644 --- a/testsuites/libtests/block10/init.c +++ b/testsuites/libtests/block10/init.c @@ -9,12 +9,6 @@ /* * Copyright (c) 2010, 2018 embedded brains GmbH. * - * embedded brains GmbH - * Dornierstr. 4 - * 82178 Puchheim - * Germany - * rt...@embedded-brains.de - * * 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. diff --git a/testsuites/sptests/spinternalerror02/init.c b/testsuites/sptests/spinternalerror02/init.c index f958e8d9a2..21c686dce7 100644 --- a/testsuites/sptests/spinternalerror02/init.c +++ b/testsuites/sptests/spinternalerror02/init.c @@ -1,12 +1,6 @@ /* * Copyright (c) 2012, 2020 embedded brains GmbH. All rights reserved. * - * embedded brains GmbH - * Donierstr. 4 - * 82178 Puchheim - * Germany - * rt...@embedded-brains.de - * * 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. -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 32/40] bsps/powerpc: Manual file header clean up
Updates #4625. --- bsps/powerpc/include/bsp/tsec.h | 31 ++--- bsps/powerpc/include/mpc83xx/mpc83xx_i2cdrv.h | 32 ++ bsps/powerpc/include/mpc83xx/mpc83xx_spidrv.h | 34 +++--- bsps/powerpc/virtex/include/bsp/irq.h | 32 ++ bsps/powerpc/virtex/irq/irq_init.c| 44 +++ bsps/powerpc/virtex5/include/bsp/irq.h| 32 ++ bsps/powerpc/virtex5/irq/irq_init.c | 35 ++- 7 files changed, 99 insertions(+), 141 deletions(-) diff --git a/bsps/powerpc/include/bsp/tsec.h b/bsps/powerpc/include/bsp/tsec.h index 6e774ebbb8..d3aaad2e65 100644 --- a/bsps/powerpc/include/bsp/tsec.h +++ b/bsps/powerpc/include/bsp/tsec.h @@ -1,21 +1,16 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file declares the MPC83xx TSEC networking driver | -\*===*/ +/* + * RTEMS support for MPC83xx + * + * This file declares the MPC83xx TSEC networking driver. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * 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. + */ #ifndef LIBCPU_POWERPC_TSEC_H #define LIBCPU_POWERPC_TSEC_H diff --git a/bsps/powerpc/include/mpc83xx/mpc83xx_i2cdrv.h b/bsps/powerpc/include/mpc83xx/mpc83xx_i2cdrv.h index 8758568876..5ee3d63536 100644 --- a/bsps/powerpc/include/mpc83xx/mpc83xx_i2cdrv.h +++ b/bsps/powerpc/include/mpc83xx/mpc83xx_i2cdrv.h @@ -1,21 +1,17 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the MPC83xx I2C driver declarations | -\*===*/ +/* + * RTEMS support for MPC83xx + * + * This file contains the MPC83xx I2C driver declarations. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * 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. + */ + #ifndef _MPC83XX_I2CDRV_H #define _MPC83XX_I2CDRV_H diff --git a/bsps/powerpc/include/mpc83xx/mpc83xx_spidrv.h b/bsps/powerpc/include/mpc83xx/mpc83xx_spidrv.h index 9fcffb114d..48212469ab 100644 --- a/bsps/powerpc/include/mpc83xx/mpc83xx_spidrv.h +++ b/bsps/powerpc/include/mpc83xx/mpc83xx_spidrv.h @@ -1,22 +1,18 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|
[PATCH 15/40] bsps/m68k/gen68360/spi/m360_spi.h: Manual file header clean up
From: Joel Sherrill Updates #4625. --- bsps/m68k/gen68360/spi/m360_spi.h | 23 +++ 1 file changed, 7 insertions(+), 16 deletions(-) diff --git a/bsps/m68k/gen68360/spi/m360_spi.h b/bsps/m68k/gen68360/spi/m360_spi.h index 1a18707fe9..9e6bc5c9c1 100644 --- a/bsps/m68k/gen68360/spi/m360_spi.h +++ b/bsps/m68k/gen68360/spi/m360_spi.h @@ -6,22 +6,13 @@ * @brief this file contains the MC68360 SPI driver declarations */ -/*===*\ -| Project: RTEMS support for MC68360 | -+-+ -|Copyright (c) 2008 | -|Embedded Brains GmbH | -|Obere Lagerstr. 30 | -|D-82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -\*===*/ +/* + * Copyright (c) 2008 embedded brains GmbH. All rights reserved. + * + * 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. + */ /** * @defgroup m68k_m360spi M360_SPIDRV Support -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 39/40] bsps: Automated IMD header file clean up
Use the same form of IMD in all copyright lines Update #4625. --- bsps/i386/pc386/ata/ide.c| 2 +- bsps/i386/pc386/ata/idecfg.c | 2 +- bsps/powerpc/gen5200/ata/pcmcia_ide.c| 2 +- bsps/powerpc/gen5200/slicetimer/slicetimer.c | 2 +- bsps/powerpc/shared/clock/clock-ppc403.c | 2 +- bsps/powerpc/virtex/include/bsp.h| 2 +- bsps/powerpc/virtex/start/bspstart.c | 4 ++-- bsps/powerpc/virtex4/include/bsp.h | 2 +- bsps/powerpc/virtex4/start/bspstart.c| 4 ++-- bsps/powerpc/virtex5/include/bsp.h | 2 +- bsps/powerpc/virtex5/start/bspstart.c| 4 ++-- 11 files changed, 14 insertions(+), 14 deletions(-) diff --git a/bsps/i386/pc386/ata/ide.c b/bsps/i386/pc386/ata/ide.c index 8b0b585d22..04cf943939 100644 --- a/bsps/i386/pc386/ata/ide.c +++ b/bsps/i386/pc386/ata/ide.c @@ -8,7 +8,7 @@ */ /* - * Copyright (c) 2003 Ingenieurbuero fuer Microcomputertechnik Th. Doerfler + * Copyright (c) 2003 IMD Ingenieurbuero fuer Microcomputertechnik * All rights reserved. * * The license and distribution terms for this file may be diff --git a/bsps/i386/pc386/ata/idecfg.c b/bsps/i386/pc386/ata/idecfg.c index 777b8bcbe0..35d4a790f2 100644 --- a/bsps/i386/pc386/ata/idecfg.c +++ b/bsps/i386/pc386/ata/idecfg.c @@ -6,7 +6,7 @@ */ /* - * Copyright (c) 2003 Ingenieurbuero fuer Microcomputertechnik Th. Doerfler + * Copyright (c) 2003 IMD Ingenieurbuero fuer Microcomputertechnik * All rights reserved. * * The license and distribution terms for this file may be diff --git a/bsps/powerpc/gen5200/ata/pcmcia_ide.c b/bsps/powerpc/gen5200/ata/pcmcia_ide.c index 33d6162c17..931e22769d 100644 --- a/bsps/powerpc/gen5200/ata/pcmcia_ide.c +++ b/bsps/powerpc/gen5200/ata/pcmcia_ide.c @@ -9,7 +9,7 @@ */ /* - * Copyright (c) 2003 IMD Ingenieurbuero fuer Microcomputertechnik Th. Doerfler. + * Copyright (c) 2003 IMD Ingenieurbuero fuer Microcomputertechnik * All rights reserved. * Copyright (c) 2003 IPR Engineering * Copyright (c) 2005 embedded brains GmbH. All rights reserved. diff --git a/bsps/powerpc/gen5200/slicetimer/slicetimer.c b/bsps/powerpc/gen5200/slicetimer/slicetimer.c index d99e0ed532..196e0df81d 100644 --- a/bsps/powerpc/gen5200/slicetimer/slicetimer.c +++ b/bsps/powerpc/gen5200/slicetimer/slicetimer.c @@ -27,7 +27,7 @@ *of this software for any purpose. * * Modifications for deriving timer clock from cpu system clock by - * Copyright (c) 1997 by Ingenieurbuero fuer Microcomputertechnik Th. Doerfler + * Copyright (c) 1997 IMD Ingenieurbuero fuer Microcomputertechnik * * COPYRIGHT (c) 1989-1999. * On-Line Applications Research Corporation (OAR). diff --git a/bsps/powerpc/shared/clock/clock-ppc403.c b/bsps/powerpc/shared/clock/clock-ppc403.c index bc744455e2..840e1c82ea 100644 --- a/bsps/powerpc/shared/clock/clock-ppc403.c +++ b/bsps/powerpc/shared/clock/clock-ppc403.c @@ -26,7 +26,7 @@ * Modifications for deriving timer clock from cpu system clock by * Thomas Doerfler * for these modifications: - * COPYRIGHT (c) 1997 by IMD, Puchheim, Germany. + * Copyright (c) 1997 IMD Ingenieurbuero fuer Microcomputertechnik * * COPYRIGHT (c) 1989-2012. * On-Line Applications Research Corporation (OAR). diff --git a/bsps/powerpc/virtex/include/bsp.h b/bsps/powerpc/virtex/include/bsp.h index b55e1a61f3..69f98f4b76 100644 --- a/bsps/powerpc/virtex/include/bsp.h +++ b/bsps/powerpc/virtex/include/bsp.h @@ -15,7 +15,7 @@ * Author:Thomas Doerfler * IMD Ingenieurbuero fuer Microcomputertechnik * - * COPYRIGHT (c) 1998 by IMD + * Copyright (c) 1998 IMD Ingenieurbuero fuer Microcomputertechnik * * Changes from IMD are covered by the original distributions terms. * This file has been derived from the papyrus BSP. diff --git a/bsps/powerpc/virtex/start/bspstart.c b/bsps/powerpc/virtex/start/bspstart.c index 11eb57c46e..641eff9071 100644 --- a/bsps/powerpc/virtex/start/bspstart.c +++ b/bsps/powerpc/virtex/start/bspstart.c @@ -12,7 +12,7 @@ * Author:Thomas Doerfler * IMD Ingenieurbuero fuer Microcomputertechnik * - * COPYRIGHT (c) 1998 by IMD + * Copyright (c) 1998 IMD Ingenieurbuero fuer Microcomputertechnik * * Changes from IMD are covered by the original distributions terms. * This file has been derived from the papyrus BSP: @@ -36,7 +36,7 @@ * with linker command file by * Thomas Doerfler * for these modifications: - * COPYRIGHT (c) 1997 by IMD, Puchheim, Germany. + * Copyright (c) 1997 IMD Ingenieurbuero fuer Microcomputertechnik * * To anyone who acknowledges that this file is provided "AS IS" * without any express or implied warranty: diff --git a/bsps/powerpc/virtex4/include/bsp.h b/bsps/powerpc/virtex4/include/bsp.h index d0ab96813d..dc9d4cd0a5 100644 --- a/bsps/powerpc/virtex4/include/bsp.h +++ b/bsps/powerpc/virtex4/include/bsp.h @@ -16,7 +16,7 @@ * Author:Thomas
[PATCH 35/40] bsps and cpukit: Manual file header clean up
Updates #4625. --- bsps/i386/pc386/ata/ide.c | 41 ++- bsps/i386/pc386/ata/idecfg.c | 33 +- cpukit/include/rtems/fsmount.h| 13 +++ cpukit/include/rtems/serdbg.h | 34 +-- cpukit/include/rtems/serdbgcnf.h | 27 +-- cpukit/include/rtems/termios_printk.h | 32 -- cpukit/include/rtems/termios_printk_cnf.h | 27 +-- cpukit/libfs/src/dosfs/msdos_format.c | 13 +++ cpukit/libmisc/fsmount/fsmount.c | 16 - cpukit/libmisc/serdbg/serdbg.c| 33 +- 10 files changed, 113 insertions(+), 156 deletions(-) diff --git a/bsps/i386/pc386/ata/ide.c b/bsps/i386/pc386/ata/ide.c index 52877cf60b..8b0b585d22 100644 --- a/bsps/i386/pc386/ata/ide.c +++ b/bsps/i386/pc386/ata/ide.c @@ -1,27 +1,20 @@ -/*===*\ -| Project: RTEMS PC386 IDE harddisc driver| -+-+ -| File: ide.c | -+-+ -|Copyright (c) 2003 IMD | -| Ingenieurbuero fuer Microcomputertechnik Th. Doerfler | -| | -| all rights reserved | -+-+ -| this file contains the BSP layer for IDE access below the | -| libchip IDE harddisc driver | -| based on a board specific driver from | -| Eugeny S. Mints, Oktet | -| | -| 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. | -| | -+-+ -| date historyID | -| ~~~ | -| 01.14.03 creation doe | -\*===*/ +/* + * RTEMS PC386 IDE harddisc driver + * + * This file contains the BSP layer for IDE access below the + * libchip IDE harddisc driver. + * based on a board specific driver from + * Eugeny S. Mints, Oktet + */ + +/* + * Copyright (c) 2003 Ingenieurbuero fuer Microcomputertechnik Th. Doerfler + * All rights reserved. + * + * 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. + */ #include diff --git a/bsps/i386/pc386/ata/idecfg.c b/bsps/i386/pc386/ata/idecfg.c index 371a6eea53..777b8bcbe0 100644 --- a/bsps/i386/pc386/ata/idecfg.c +++ b/bsps/i386/pc386/ata/idecfg.c @@ -1,21 +1,18 @@ -/*===*\ -| Project: RTEMS PC386 IDE harddisc driver tables | -+-+ -| File: idecfg.c | -+-+ -|Copyright (c) 2003 IMD | -| Ingenieurbuero fuer Microcomputertechnik Th. Doerfler | -| | -| all rights reserved | -+-+ -| this file contains the table of functions for the BSP layer | -| for IDE access below the libchip IDE harddisc driver| -| | -+-+ -| date historyID | -| ~~~ | -| 01.14.03 creation doe | -\*===*/ +/* + * RTEMS PC386 IDE harddisc driver tables + * + * This file contains the table of functions for the BSP layer + * for IDE access below the libchip IDE harddisc driver. + */ + +/* + * Copyright (c) 2003 Ingenieurbuero fuer Microcomputertechnik Th. Doerfler + * All rights reserved. + * + * 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. + */ #include #include diff --git a/cpukit/include/rtems/fsmount.h b/cpukit/include/rtems/fsmount.h index
[PATCH 25/40] bsps/testsuites/: Scripted embedded brains header file clean up
From: Joel Sherrill Updates #4625. --- testsuites/benchmarks/dhrystone/init.c | 6 -- testsuites/benchmarks/linpack/init.c | 6 -- testsuites/benchmarks/whetstone/init.c | 6 -- testsuites/fstests/fsbdpart01/init.c | 6 -- testsuites/fstests/fsdosfsformat01/init.c | 6 -- testsuites/fstests/fsdosfsname01/create_files.cs | 6 -- testsuites/fstests/fsdosfsname01/image_bin_le_multibyte.h | 6 -- testsuites/fstests/fsdosfsname01/image_bin_le_singlebyte.h | 6 -- testsuites/fstests/fsdosfsname01/init.c| 6 -- testsuites/fstests/fsdosfsname02/init.c| 6 -- testsuites/fstests/fsdosfssync01/init.c| 6 -- testsuites/fstests/fsdosfswrite01/init.c | 6 -- testsuites/fstests/fsfseeko01/init.c | 6 -- testsuites/fstests/fsimfsconfig01/init.c | 6 -- testsuites/fstests/fsimfsconfig02/init.c | 6 -- testsuites/fstests/fsimfsconfig03/init.c | 6 -- testsuites/fstests/fsjffs2gc01/init.c | 6 -- testsuites/fstests/fsnofs01/init.c | 6 -- testsuites/fstests/fsrofs01/init.c | 6 -- testsuites/fstests/jffs2_support/fs_config.h | 6 -- testsuites/fstests/jffs2_support/fs_support.c | 6 -- testsuites/libtests/block01/init.c | 6 -- testsuites/libtests/block02/init.c | 6 -- testsuites/libtests/block03/init.c | 6 -- testsuites/libtests/block04/init.c | 6 -- testsuites/libtests/block05/init.c | 6 -- testsuites/libtests/block07/init.c | 6 -- testsuites/libtests/block09/init.c | 6 -- testsuites/libtests/block10/init.c | 4 ++-- testsuites/libtests/block11/init.c | 6 -- testsuites/libtests/block12/init.c | 6 -- testsuites/libtests/block13/init.c | 6 -- testsuites/libtests/block14/init.c | 6 -- testsuites/libtests/block15/init.c | 6 -- testsuites/libtests/block16/init.c | 6 -- testsuites/libtests/block17/init.c | 6 -- testsuites/libtests/crypt01/init.c | 6 -- testsuites/libtests/defaultconfig01/init.c | 6 -- testsuites/libtests/exit01/init.c | 6 -- testsuites/libtests/exit02/init.c | 6 -- testsuites/libtests/flashdisk01/init.c | 6 -- testsuites/libtests/flashdisk01/test-file-system.c | 6 -- testsuites/libtests/flashdisk01/test-file-system.h | 6 -- testsuites/libtests/getentropy01/init.c| 6 -- testsuites/libtests/i2c01/init.c | 6 -- testsuites/libtests/libfdt01/init.c| 6 -- testsuites/libtests/libfdt01/some.dts | 6 -- testsuites/libtests/md501/init.c | 6 -- testsuites/libtests/newlib01/init.c| 6 -- testsuites/libtests/ofw01/some.dts | 6 -- testsuites/libtests/pwdgrp01/init.c| 6 -- testsuites/libtests/pwdgrp02/init.c| 6 -- testsuites/libtests/rbheap01/init.c| 6 -- testsuites/libtests/sha/init.c | 6 -- testsuites/libtests/shell01/init.c | 6 -- testsuites/libtests/sparsedisk01/init.c| 6 -- testsuites/libtests/spi01/init.c | 6 -- testsuites/libtests/termios09/init.c | 6 -- testsuites/libtests/utf8proc01/init.c | 6 -- testsuites/psxtests/psx15/init.c | 6 -- testsuites/psxtests/psxcleanup02/init.c| 6 -- testsuites/psxtests/psxcleanup02/main.c| 6 -- testsuites/psxtests/psxclockrealtime01/init.c | 6 -- testsuites/psxtests/psxconfig01/init.c | 6 -- testsuites/psxtests/psxglobalcon01/init.cc | 6 -- testsuites/psxtests/psxglobalcon02/init.cc | 6 -- testsuites/psxtests/psxthreadname01/init.c | 6 -- testsuites/smptests/smpatomic01/init.c | 6 -- testsuites/smptests/smpclock01/init.c | 6 -- testsuites/smptests/smpfatal01/init.c
[PATCH 31/40] bsps/powerpc/gen5200: Manual file header clean up
Updates #4625. --- bsps/powerpc/gen5200/ata/idecfg.c | 32 +++- bsps/powerpc/gen5200/bestcomm/bestcomm_glue.c | 32 +++- bsps/powerpc/gen5200/i2c/i2cdrv.c | 37 ++- bsps/powerpc/gen5200/i2c/mpc5200mbus.c| 35 ++ bsps/powerpc/gen5200/i2c/mpc5200mbus.h| 31 bsps/powerpc/gen5200/include/bsp.h| 34 +++-- .../include/bsp/bestcomm/bestcomm_glue.h | 32 +++- bsps/powerpc/gen5200/include/bsp/mpc5200.h| 34 +++-- bsps/powerpc/gen5200/include/bsp/mscan.h | 35 +++--- bsps/powerpc/gen5200/include/bsp/slicetimer.h | 35 +++--- bsps/powerpc/gen5200/mscan/mscan.c| 31 +++- bsps/powerpc/gen5200/mscan/mscan_int.h| 35 +++--- bsps/powerpc/gen5200/rtc/pcf8563.c| 32 +--- bsps/powerpc/gen5200/rtc/pcf8563.h| 32 +--- bsps/powerpc/gen5200/rtc/todcfg.c | 32 +--- 15 files changed, 181 insertions(+), 318 deletions(-) diff --git a/bsps/powerpc/gen5200/ata/idecfg.c b/bsps/powerpc/gen5200/ata/idecfg.c index 8f274f3ce1..1624f9bc76 100644 --- a/bsps/powerpc/gen5200/ata/idecfg.c +++ b/bsps/powerpc/gen5200/ata/idecfg.c @@ -1,21 +1,17 @@ -/*===*\ -| Project: RTEMS generic MPC5200 BSP | -+-+ -|Copyright (c) 2005 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the IDE configuration| -\*===*/ +/* + * RTEMS generic MPC5200 BSP + * + * This file contains the IDE configuration. + */ + +/* + * Copyright (c) 2005 embedded brains GmbH. All rights reserved. + * + * 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. + */ + #include #include #include diff --git a/bsps/powerpc/gen5200/bestcomm/bestcomm_glue.c b/bsps/powerpc/gen5200/bestcomm/bestcomm_glue.c index 9971faec2b..4981247d39 100644 --- a/bsps/powerpc/gen5200/bestcomm/bestcomm_glue.c +++ b/bsps/powerpc/gen5200/bestcomm/bestcomm_glue.c @@ -1,21 +1,17 @@ -/*===*\ -| Project: RTEMS generic MPC5200 BSP | -+-+ -|Copyright (c) 2004-2005 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains glue functions to the Freescale BestComm API | -\*===*/ +/* + * RTEMS generic MPC5200 BSP + * + * This file contains glue functions to the Freescale BestComm API. + */ + +/* + * Copyright (c) 2004-2005 embedded brains GmbH. All rights reserved. + * + * 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. + */ + #include #include #include diff --git a/bsps/powerpc/gen5200/i2c/i2cdrv.c b/bsps/powerpc/gen5200/i2c/i2cdrv.c index c1a5a93764..1d612f1ad6 100644 ---
[PATCH 30/40] bsps/powerpc: Manual file header clean up
Updates #4625. --- bsps/powerpc/mpc55xxevb/i2c/i2c_init.c | 31 +++- bsps/powerpc/qemuppc/irq/irq_init.c | 31 +++- bsps/powerpc/tqm8xx/include/bsp/8xx_immap.h | 40 + bsps/powerpc/virtex4/include/bsp/irq.h | 32 - bsps/powerpc/virtex4/irq/irq_init.c | 35 -- 5 files changed, 71 insertions(+), 98 deletions(-) diff --git a/bsps/powerpc/mpc55xxevb/i2c/i2c_init.c b/bsps/powerpc/mpc55xxevb/i2c/i2c_init.c index dfcc621a31..d414fe61f0 100644 --- a/bsps/powerpc/mpc55xxevb/i2c/i2c_init.c +++ b/bsps/powerpc/mpc55xxevb/i2c/i2c_init.c @@ -1,21 +1,16 @@ -/*===*\ -| Project: RTEMS support for GWLCFM | -+-+ -|Copyright (c) 2010 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the low level MPC5516 I2C driver parameters | -\*===*/ +/* + * RTEMS support for GWLCFM + * + * This file contains the low level MPC5516 I2C driver parameters. + */ + +/* + * Copyright (c) 2010 embedded brains GmbH. All rights reserved. + * + * 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. + */ #include diff --git a/bsps/powerpc/qemuppc/irq/irq_init.c b/bsps/powerpc/qemuppc/irq/irq_init.c index 2171a8d8dd..c3e0aca915 100644 --- a/bsps/powerpc/qemuppc/irq/irq_init.c +++ b/bsps/powerpc/qemuppc/irq/irq_init.c @@ -1,21 +1,16 @@ -/*===*\ -| Project: RTEMS generic MPC83xx BSP | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file integrates the IPIC irq controller| -\*===*/ +/* + * RTEMS generic MPC83xx BSP + * + * This file integrates the IPIC irq controller. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * 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. + */ #include diff --git a/bsps/powerpc/tqm8xx/include/bsp/8xx_immap.h b/bsps/powerpc/tqm8xx/include/bsp/8xx_immap.h index a352d2c2a7..e6347ea0c6 100644 --- a/bsps/powerpc/tqm8xx/include/bsp/8xx_immap.h +++ b/bsps/powerpc/tqm8xx/include/bsp/8xx_immap.h @@ -1,30 +1,24 @@ -/*===*\ -| Project: RTEMS BSP support for TQ modules | -+-+ -| Partially based on the code references which are named below. | -| Adaptions, modifications, enhancements and any recent parts of | -| the code are: | -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim
[PATCH 29/40] bsps/powerpc/gen83xx: Manual file header clean up
Updates #4625. --- bsps/powerpc/gen83xx/dev/mpc83xx_i2cdrv.c | 32 - bsps/powerpc/gen83xx/dev/mpc83xx_spidrv.c | 34 --- bsps/powerpc/gen83xx/i2c/i2c_init.c | 30 +++- bsps/powerpc/gen83xx/include/bsp.h| 30 +++- bsps/powerpc/gen83xx/include/bsp/hwreg_vals.h | 30 +++- bsps/powerpc/gen83xx/include/bsp/irq.h| 30 +++- bsps/powerpc/gen83xx/irq/irq.c| 31 +++-- bsps/powerpc/gen83xx/spi/spi_init.c | 34 --- bsps/powerpc/gen83xx/start/start.S| 30 +++- 9 files changed, 116 insertions(+), 165 deletions(-) diff --git a/bsps/powerpc/gen83xx/dev/mpc83xx_i2cdrv.c b/bsps/powerpc/gen83xx/dev/mpc83xx_i2cdrv.c index 51c36eea01..79e658ce45 100644 --- a/bsps/powerpc/gen83xx/dev/mpc83xx_i2cdrv.c +++ b/bsps/powerpc/gen83xx/dev/mpc83xx_i2cdrv.c @@ -1,21 +1,17 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the MPC83xx I2C driver | -\*===*/ +/* + * RTEMS support for MPC83xx + * + * This file contains the MPC83xx I2C driver. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * 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. + */ + #include #include #include diff --git a/bsps/powerpc/gen83xx/dev/mpc83xx_spidrv.c b/bsps/powerpc/gen83xx/dev/mpc83xx_spidrv.c index 4261e23040..5dc29d327c 100644 --- a/bsps/powerpc/gen83xx/dev/mpc83xx_spidrv.c +++ b/bsps/powerpc/gen83xx/dev/mpc83xx_spidrv.c @@ -1,22 +1,18 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright (c) 2007 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the MPC83xx SPI driver | -| NOTE: it uses the same API as the I2C driver| -\*===*/ +/* + * RTEMS support for MPC83xx + * + * This file contains the MPC83xx SPI driver. + * NOTE: it uses the same API as the I2C driver. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * 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. + */ + #include #include #include diff --git a/bsps/powerpc/gen83xx/i2c/i2c_init.c b/bsps/powerpc/gen83xx/i2c/i2c_init.c index 40a88fda54..60fddbfb5b 100644 --- a/bsps/powerpc/gen83xx/i2c/i2c_init.c +++ b/bsps/powerpc/gen83xx/i2c/i2c_init.c @@ -1,22 +1,16 @@ -/*===*\ -| Project: RTEMS support for MPC83xx | -+-+ -|Copyright
[PATCH 27/40] bsps/shared: Manual file header clean up
Updates #4625. --- bsps/shared/dev/display/disp_fonts.h| 32 ++-- bsps/shared/dev/display/disp_hcms29xx.c | 33 +++-- bsps/shared/dev/display/font_hcms29xx.c | 31 ++- bsps/shared/dev/display/font_hcms29xx.h | 31 ++- bsps/shared/dev/i2c/spi-flash-m25p40.c | 28 + bsps/shared/dev/i2c/spi-fram-fm25l256.c | 28 + bsps/shared/dev/i2c/spi-memdrv.c| 29 +- 7 files changed, 87 insertions(+), 125 deletions(-) diff --git a/bsps/shared/dev/display/disp_fonts.h b/bsps/shared/dev/display/disp_fonts.h index b988db531d..49caf05906 100644 --- a/bsps/shared/dev/display/disp_fonts.h +++ b/bsps/shared/dev/display/disp_fonts.h @@ -1,22 +1,16 @@ -/*===*\ -| Project: display driver for HCMS29xx| -+-+ -| File: disp_fonts.h | -+-+ -|Copyright (c) 2008 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| This file declares general data structures for font management | -\*===*/ +/* + * Display driver for HCMS29xx. + * + * This file declares general data structures for font management. + */ + +/* + * Copyright (c) 2008 embedded brains GmbH. All rights reserved. + * + * 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. + */ #ifndef DISP_FONTS_H #define DISP_FONTS_H diff --git a/bsps/shared/dev/display/disp_hcms29xx.c b/bsps/shared/dev/display/disp_hcms29xx.c index 656820fb50..6990f042db 100644 --- a/bsps/shared/dev/display/disp_hcms29xx.c +++ b/bsps/shared/dev/display/disp_hcms29xx.c @@ -1,22 +1,17 @@ -/*===*\ -| Project: display driver for HCMS29xx| -+-+ -| File: disp_hcms29xx.c | -+-+ -|Copyright (c) 2008 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -+-+ -| this file contains the SPI based driver for a HCMS29xx 4 digit | -| alphanumeric LED display| -\*===*/ +/* + * Display driver for HCMS29xx. + * + * This file contains the SPI based driver for a HCMS29xx 4 digit + * alphanumeric LED display. + */ + +/* + * Copyright (c) 2008 embedded brains GmbH. All rights reserved. + * + * 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. + */ #include #include diff --git a/bsps/shared/dev/display/font_hcms29xx.c b/bsps/shared/dev/display/font_hcms29xx.c index 07bf61c3dd..8e8d25f7b6 100644 --- a/bsps/shared/dev/display/font_hcms29xx.c +++ b/bsps/shared/dev/display/font_hcms29xx.c @@ -1,21 +1,16 @@ -/*===*\ -| Project: display driver for HCMS29xx| -+-+ -| File: font_hcms29xx.c |
[PATCH 28/40] bsps/powerpc/tqm8xx: Manual file header clean up
Updates #4625. --- bsps/powerpc/tqm8xx/btimer/btimer.c | 37 ++--- bsps/powerpc/tqm8xx/console/console.c | 34 +++ bsps/powerpc/tqm8xx/include/bsp.h | 12 ++-- bsps/powerpc/tqm8xx/include/bsp/irq.h | 40 --- bsps/powerpc/tqm8xx/include/bsp/spi.h | 32 ++--- bsps/powerpc/tqm8xx/include/bsp/tqm.h | 36 ++-- bsps/powerpc/tqm8xx/irq/irq.c | 39 +++--- bsps/powerpc/tqm8xx/spi/spi.c | 32 ++--- bsps/powerpc/tqm8xx/start/mmutlbtab.c | 31 + bsps/powerpc/tqm8xx/start/start.S | 33 ++ 10 files changed, 124 insertions(+), 202 deletions(-) diff --git a/bsps/powerpc/tqm8xx/btimer/btimer.c b/bsps/powerpc/tqm8xx/btimer/btimer.c index bb90a11764..ff1192b256 100644 --- a/bsps/powerpc/tqm8xx/btimer/btimer.c +++ b/bsps/powerpc/tqm8xx/btimer/btimer.c @@ -1,25 +1,18 @@ -/*===*\ -| Project: RTEMS TQM8xx BSP | -+-+ -| This file has been adapted to MPC8xx by | -|Thomas Doerfler | -|Copyright (c) 2008 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -| | -| See the other copyright notice below for the original parts.| -+-+ -| 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. | -| | -+-+ -| this file contains the console driver | -\*===*/ +/* + * RTEMS TQM8xx BSP + * + * This file contains the console driver. + */ + +/* + * Copyright (c) 2008 Thomas Doerfler, embedded brains GmbH. + * All rights reserved. + * + * 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. + */ + /* * benchmark_timer_initialize() * diff --git a/bsps/powerpc/tqm8xx/console/console.c b/bsps/powerpc/tqm8xx/console/console.c index d5b0569707..0e0dace33e 100644 --- a/bsps/powerpc/tqm8xx/console/console.c +++ b/bsps/powerpc/tqm8xx/console/console.c @@ -1,27 +1,8 @@ -/*===*\ -| Project: RTEMS TQM8xx BSP | -+-+ -| This file has been adapted to MPC8xx by | -|Thomas Doerfler | -|Copyright (c) 2008 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -| | -| See the other copyright notice below for the original parts.| -+-+ -| 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. | -| | -+-+ -| this file contains the console driver | -\*===*/ -/* derived from: */ /* + * RTEMS TQM8xx BSP + * + * This file contains the console driver. + * * SMC1/2 SCC1..4 raw console serial I/O. * adapted to work with up to 4 SCC and 2 SMC * @@ -29,7 +10,9 @@ * * To run with interrupt-driven I/O, ensure m8xx_smc1_interrupt * is set before calling the initialization routine. - * + */ + +/* * Author: *W. Eric Norum *Saskatchewan Accelerator Laboratory @@ -41,6 +24,9 @@ *
[PATCH 19/40] bsps/arm/: Scripted embedded brains header file clean up
From: Joel Sherrill Updates #4625. --- bsps/arm/altera-cyclone-v/console/console-config.c| 6 -- bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.c | 6 -- bsps/arm/altera-cyclone-v/i2c/i2cdrv-config.h | 6 -- bsps/arm/altera-cyclone-v/i2c/i2cdrv.c| 6 -- bsps/arm/altera-cyclone-v/include/bsp.h | 6 -- bsps/arm/altera-cyclone-v/include/bsp/i2cdrv.h| 6 -- bsps/arm/altera-cyclone-v/include/bsp/irq.h | 6 -- bsps/arm/altera-cyclone-v/include/tm27.h | 6 -- bsps/arm/altera-cyclone-v/rtc/rtc.c | 6 -- bsps/arm/altera-cyclone-v/start/bspclean.c| 6 -- bsps/arm/altera-cyclone-v/start/bspreset.c| 6 -- bsps/arm/altera-cyclone-v/start/bspsmp.c | 6 -- bsps/arm/altera-cyclone-v/start/bspstart.c| 6 -- bsps/arm/altera-cyclone-v/start/bspstarthooks.c | 6 -- bsps/arm/altera-cyclone-v/start/mmu-config.c | 6 -- bsps/arm/atsam/clock/systick-freq.c | 6 -- bsps/arm/atsam/console/console.c | 6 -- bsps/arm/atsam/console/debug-console.c| 6 -- bsps/arm/atsam/i2c/atsam_i2c_bus.c| 6 -- bsps/arm/atsam/i2c/atsam_i2c_init.c | 6 -- bsps/arm/atsam/include/bsp.h | 6 -- bsps/arm/atsam/include/bsp/atsam-clock-config.h | 6 -- bsps/arm/atsam/include/bsp/atsam-i2c.h| 6 -- bsps/arm/atsam/include/bsp/atsam-spi.h| 6 -- bsps/arm/atsam/include/bsp/i2c.h | 6 -- bsps/arm/atsam/include/bsp/iocopy.h | 6 -- bsps/arm/atsam/include/bsp/irq.h | 6 -- bsps/arm/atsam/include/bsp/pin-config.h | 6 -- bsps/arm/atsam/include/bsp/power.h| 6 -- bsps/arm/atsam/include/bsp/sc16is752.h| 6 -- bsps/arm/atsam/include/bsp/spi.h | 6 -- bsps/arm/atsam/rtc/rtc-config.c | 6 -- bsps/arm/atsam/spi/atsam_spi_init.c | 6 -- bsps/arm/atsam/spi/sc16is752.c| 6 -- bsps/arm/atsam/start/bspstart.c | 6 -- bsps/arm/atsam/start/bspstarthooks.c | 6 -- bsps/arm/atsam/start/getentropy-trng.c| 6 -- bsps/arm/atsam/start/iocopy.c | 6 -- bsps/arm/atsam/start/pin-config.c | 6 -- bsps/arm/atsam/start/pmc-config.c | 6 -- bsps/arm/atsam/start/power-clock.c| 6 -- bsps/arm/atsam/start/power-rtc.c | 6 -- bsps/arm/atsam/start/power.c | 6 -- bsps/arm/atsam/start/restart.c| 6 -- bsps/arm/atsam/start/sdram-config.c | 6 -- bsps/arm/beagle/start/bspstart.c | 6 -- bsps/arm/beagle/start/bspstarthooks.c | 6 -- bsps/arm/beagle/start/bspstartmmu.c | 6 -- bsps/arm/imx/console/console-config.c | 6 -- bsps/arm/imx/i2c/imx-i2c.c| 6 -- bsps/arm/imx/include/arm/freescale/imx/imx_ecspireg.h | 6 -- bsps/arm/imx/include/arm/freescale/imx/imx_gpcreg.h | 6 -- bsps/arm/imx/include/arm/freescale/imx/imx_i2creg.h | 6 -- bsps/arm/imx/include/arm/freescale/imx/imx_srcreg.h | 6 -- bsps/arm/imx/include/arm/freescale/imx/imx_uartreg.h | 6 -- bsps/arm/imx/include/bsp.h| 6 -- bsps/arm/imx/include/bsp/irq.h| 6 -- bsps/arm/imx/include/tm27.h | 6 -- bsps/arm/imx/spi/imx-ecspi.c | 6 -- bsps/arm/imx/start/bspreset.c | 6 -- bsps/arm/imx/start/bspsmp.c | 6 -- bsps/arm/imx/start/bspstart.c | 6 -- bsps/arm/imx/start/bspstarthooks.c| 6 -- bsps/arm/imx/start/ccm.c | 6 -- bsps/arm/imxrt/start/bspstarthooks.c | 6 -- bsps/arm/include/bsp/arm-a9mpcore-irq.h | 6 -- bsps/arm/include/bsp/arm-a9mpcore-regs.h | 6 -- bsps/arm/include/bsp/arm-a9mpcore-start.h | 6 -- bsps/arm/include/bsp/arm-cp15-start.h | 6 -- bsps/arm/include/bsp/arm-errata.h | 6 -- bsps/arm/include/bsp/arm-pl050-regs.h | 6 -- bsps/arm/include/bsp/arm-pl050.h | 6 -- bsps/arm/include/bsp/arm-pl111-fb.h | 6 -- bsps/arm/include/bsp/arm-pl111-regs.h | 6 -- bsps/arm/include/bsp/arm-release-id.h | 6 --
[PATCH 17/40] m68k/genmcf548x/: Manual file header clean up
From: Joel Sherrill Updates #4625. --- bsps/m68k/genmcf548x/btimer/btimer.c | 72 +++ bsps/m68k/genmcf548x/clock/clock.c| 70 +++--- bsps/m68k/genmcf548x/include/bsp/irq.h| 6 -- .../genmcf548x/irq/intc-icr-init-values.c | 6 -- bsps/m68k/genmcf548x/irq/irq.c| 6 -- bsps/m68k/genmcf548x/mcdma/mcdma_glue.c | 32 - bsps/m68k/genmcf548x/start/bspstart.c | 68 +++--- bsps/m68k/genmcf548x/start/cache.c| 6 -- bsps/m68k/genmcf548x/start/init548x.c | 70 +++--- bsps/m68k/genmcf548x/start/linkcmds.COBRA5475 | 4 +- .../genmcf548x/start/linkcmds.m5484FireEngine | 4 +- .../start/linkcmds.m5484FireEngine.flash | 4 +- bsps/m68k/genmcf548x/start/start.S| 4 +- 13 files changed, 125 insertions(+), 227 deletions(-) diff --git a/bsps/m68k/genmcf548x/btimer/btimer.c b/bsps/m68k/genmcf548x/btimer/btimer.c index acac6f8f9b..9b95fd32cd 100644 --- a/bsps/m68k/genmcf548x/btimer/btimer.c +++ b/bsps/m68k/genmcf548x/btimer/btimer.c @@ -1,48 +1,30 @@ -/*===*\ -| Project: RTEMS generic mcf548x BSP | -+-+ -| File: timer.c | -+-+ -| The file contains the diagnostic timer code of generic MCF548x | -| BSP.| -+-+ -|Copyright (c) 2007 | -|Embedded Brains GmbH | -|Obere Lagerstr. 30 | -|D-82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| | -| Parts of the code has been derived from the "dBUG source code" | -| package Freescale is providing for M548X EVBs. The usage of | -| the modified or unmodified code and it's integration into the | -| generic mcf548x BSP has been done according to the Freescale| -| license terms. | -| | -| The Freescale license terms can be reviewed in the file | -| | -|Freescale_license.txt| -| | -+-+ -| | -| The generic mcf548x BSP has been developed on the basic | -| structures and modules of the av5282 BSP. | -| | -+-+ -| | -| 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. | -| | -+-+ -| | -| date historyID | -| ~~~ | -| 12.11.071.0ras | -| | -\*===*/ +/* + * RTEMS generic mcf548x BSP + * + * The file contains the diagnostic timer code of generic MCF548x + * BSP. + * + * Parts of the code has been derived from the "dBUG source code" + * package Freescale is providing for M548X EVBs. The usage of + * the modified or unmodified code and it's integration into the + * generic mcf548x BSP has been done according to the Freescale + * license terms. + * + * The Freescale license terms can be reviewed in the file + * + *Freescale_license.txt + * + * The generic mcf548x BSP has been developed on the basic + * structures and modules of the av5282 BSP. + */ + +/* + * Copyright (c) 2007 embedded brains GmbH. All rights reserved. + * + * The license and distribution terms for this file may be + * found in the file LICENSE in
[PATCH 14/40] bsps/lm32/include/bsp/irq.h: manual file header clean up
From: Joel Sherrill Updates #4625. --- bsps/lm32/include/bsp/irq.h | 7 +-- 1 file changed, 1 insertion(+), 6 deletions(-) diff --git a/bsps/lm32/include/bsp/irq.h b/bsps/lm32/include/bsp/irq.h index 416af841a7..6e6b74feaf 100644 --- a/bsps/lm32/include/bsp/irq.h +++ b/bsps/lm32/include/bsp/irq.h @@ -9,12 +9,7 @@ /* * Based on concepts of Pavel Pisa, Till Straumann and Eric Valette. * - * Copyright (c) 2008, 2009, 2010 - * embedded brains GmbH - * Obere Lagerstr. 30 - * D-82178 Puchheim - * Germany - * + * Copyright (c) 2008, 2009, 2010 embedded brains GmbH. All rights reserved. * * The license and distribution terms for this file may be * found in the file LICENSE in this distribution or at -- 2.34.1 ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
[PATCH 37/40] bsps/powerpc/gen5200: Manual Header clean up
Update #4625. --- bsps/powerpc/gen5200/console/console.c | 135 +- bsps/powerpc/gen5200/include/bsp/irq.h | 120 +--- bsps/powerpc/gen5200/include/bsp/nvram.h | 112 +-- bsps/powerpc/gen5200/irq/irq.c | 94 +++- bsps/powerpc/gen5200/slicetimer/slicetimer.c | 142 ++- bsps/powerpc/gen5200/start/bspstart.c| 141 ++ bsps/powerpc/gen5200/start/start.S | 135 ++ 7 files changed, 262 insertions(+), 617 deletions(-) diff --git a/bsps/powerpc/gen5200/console/console.c b/bsps/powerpc/gen5200/console/console.c index 7b7a704ee4..eecf231062 100644 --- a/bsps/powerpc/gen5200/console/console.c +++ b/bsps/powerpc/gen5200/console/console.c @@ -1,99 +1,42 @@ -/*===*\ -| Project: RTEMS generic MPC5200 BSP | -+-+ -| Partially based on the code references which are named below. | -| Adaptions, modifications, enhancements and any recent parts of | -| the code are: | -|Copyright (c) 2005 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the console driver functions | -\*===*/ -/***/ -/* */ -/* Module: console.c */ -/* Date: 07/17/2003 */ -/* Purpose: RTEMS MPC5x00 console driver*/ -/* */ -/*-*/ -/* */ -/* Description: */ -/* */ -/* The PSCs of mpc5200 are assigned as follows*/ -/* */ -/* Channel Device Minor Note */ -/*PSC1 /dev/tty0 0 */ -/*PSC2 /dev/tty1 1 */ -/*PSC3 /dev/tty2 2 */ -/* */ -/*-*/ -/* */ -/* Code */ -/* References: Serial driver for MPC8260ads*/ -/* Module: console-generic.c */ -/* Project: RTEMS 4.6.0pre1 / MPC8260ads BSP*/ -/* Version 1.3 */ -/* Date: 2002/11/04 */ -/* */ -/* Author(s) / Copyright(s): */ -/* */ -/* Author: Jay Monkman (jmonk...@frasca.com) */ -/* Copyright (C) 1998 by Frasca International, Inc. */ -/* */ -/* Derived from c/src/lib/libbsp/m68k/gen360/console/console.c */ -/* written by: */ -/* W. Eric Norum */ -/* Saskatchewan Accelerator Laboratory */ -/* University of Saskatchewan*/ -/* Saskatoon, Saskatchewan, CANADA
[PATCH 40/40] bsps/m68k: Restore license file
Quite some files in the bsps/m68k/genmcf548x mention a
Freescale_license.txt file. The file has been accidentally removed
during the source reorganization in 2018. This commit restores it and
moves it to the right location for licenses.
Update #4625.
---
LICENSE.Freescale | 132 ++
bsps/m68k/genmcf548x/README | 2 +-
bsps/m68k/genmcf548x/btimer/btimer.c | 2 +-
bsps/m68k/genmcf548x/clock/clock.c| 2 +-
bsps/m68k/genmcf548x/console/console.c| 2 +-
bsps/m68k/genmcf548x/include/bsp.h| 2 +-
bsps/m68k/genmcf548x/start/init548x.c | 2 +-
bsps/m68k/genmcf548x/start/linkcmds.COBRA5475 | 2 +-
.../genmcf548x/start/linkcmds.m5484FireEngine | 2 +-
.../start/linkcmds.m5484FireEngine.flash | 2 +-
bsps/m68k/genmcf548x/start/start.S| 2 +-
bsps/m68k/include/mcf548x/mcf548x.h | 2 +-
12 files changed, 143 insertions(+), 11 deletions(-)
create mode 100644 LICENSE.Freescale
diff --git a/LICENSE.Freescale b/LICENSE.Freescale
new file mode 100644
index 00..b844714dce
--- /dev/null
+++ b/LICENSE.Freescale
@@ -0,0 +1,132 @@
+FREESCALE SEMICONDUCTOR SOFTWARE LICENSE AGREEMENT
+
+This is a legal agreement between you (either as an individual or as an
+authorized representative of your employer) and Freescale Semiconductor,
+Inc. ("Freescale"). It concerns your rights to use this file and any
+accompanying written materials (the "Software"). In consideration for
+Freescale allowing you to access the Software, you are agreeing to be
+bound by the terms of this Agreement. If you do not agree to all of the
+terms of this Agreement, do not download the Software. If you change your
+mind later, stop using the Software and delete all copies of the Software
+in your possession or control. Any copies of the Software that you have
+already distributed, where permitted, and do not destroy will continue
+to be governed by this Agreement. Your prior use will also continue to
+be governed by this Agreement.
+
+LICENSE GRANT. Freescale grants to you, free of charge, the
+non-exclusive, non-transferable right (1) to use the Software, (2) to
+reproduce the Software, (3) to prepare derivative works of the Software,
+(4) to distribute the Software and derivative works thereof in source
+(human-readable) form and object (machine readable) form, and (5) to
+sublicense to others the right to use the distributed Software. If you
+violate any of the terms or restrictions of this Agreement, Freescale
+may immediately terminate this Agreement, and require that you stop
+using and delete all copies of the Software in your possession or control.
+
+COPYRIGHT. The Software is licensed to you, not sold. Freescale
+owns the Software, and United States copyright laws and international
+treaty provisions protect the Software. Therefore, you must treat the
+Software like any other copyrighted material (e.g. a book or musical
+recording). You may not use or copy the Software for any other purpose
+than what is described in this Agreement. Except as expressly provided
+herein, Freescale does not grant to you any express or implied rights
+under any Freescale or third-party patents, copyrights, trademarks, or
+trade secrets. Additionally, you must reproduce and apply any copyright or
+other proprietary rights notices included on or embedded in the Software
+to any copies or derivative works made thereof, in whole or in part,
+if any.
+
+SUPPORT. Freescale is NOT obligated to provide any support, upgrades or
+new releases of the Software. If you wish, you may contact Freescale and
+report problems and provide suggestions regarding the Software. Freescale
+has no obligation whatsoever to respond in any way to such a problem
+report or suggestion. Freescale may make changes to the Software at any
+time, without any obligation to notify or provide updated versions of
+the Software to you.
+
+NO WARRANTY. TO THE MAXIMUM EXTENT PERMITTED BY LAW, FREESCALE EXPRESSLY
+DISCLAIMS ANY WARRANTY FOR THE SOFTWARE. THE SOFTWARE IS PROVIDED AS
+IS, WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESS OR IMPLIED, INCLUDING,
+WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS
+FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT. YOU ASSUME THE ENTIRE RISK
+ARISING OUT OF THE USE OR PERFORMANCE OF THE SOFTWARE, OR ANY SYSTEMS
+YOU DESIGN USING THE SOFTWARE (IF ANY). NOTHING IN THIS AGREEMENT MAY BE
+CONSTRUED AS A WARRANTY OR REPRESENTATION BY FREESCALE THAT THE SOFTWARE
+OR ANY DERIVATIVE WORK DEVELOPED WITH OR INCORPORATING THE SOFTWARE
+WILL BE FREE FROM INFRINGEMENT OF THE INTELLECTUAL PROPERTY RIGHTS OF
+THIRD PARTIES.
+
+INDEMNITY. You agree to fully defend and indemnify Freescale from any and
+all claims, liabilities, and costs (including reasonable attorney's fees)
+related to (1) your use (including your sublicensee's use, if permitted)
+of the Software or (2) your violation of the terms and
[PATCH 34/40] bsps/powerpc/gen5200: Manual file header clean up
This cleans some of the more complex headers including IPR. Updates #4625. --- bsps/powerpc/gen5200/ata/pcmcia_ide.c | 96 +- bsps/powerpc/gen5200/ata/pcmcia_ide.h | 78 -- bsps/powerpc/gen5200/nvram/m93cxx.h | 101 +++ bsps/powerpc/gen5200/nvram/nvram.c| 110 -- 4 files changed, 94 insertions(+), 291 deletions(-) diff --git a/bsps/powerpc/gen5200/ata/pcmcia_ide.c b/bsps/powerpc/gen5200/ata/pcmcia_ide.c index ca1c98d250..33d6162c17 100644 --- a/bsps/powerpc/gen5200/ata/pcmcia_ide.c +++ b/bsps/powerpc/gen5200/ata/pcmcia_ide.c @@ -1,79 +1,23 @@ -/*===*\ -| Project: RTEMS generic MPC5200 BSP | -+-+ -| Partially based on the code references which are named below. | -| Adaptions, modifications, enhancements and any recent parts of | -| the code are: | -|Copyright (c) 2005 | -|embedded brains GmbH | -|Obere Lagerstr. 30 | -|82178 Puchheim | -|Germany | -|rt...@embedded-brains.de | -+-+ -| 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. | -| | -+-+ -| this file contains the PCMCIA IDE access functions | -\*===*/ -/***/ -/* */ -/* Module: pcmcia_ide.c*/ -/* Date: 07/17/2003 */ -/* Purpose: RTEMS MPC5x00 PCMCIA IDE harddisk driver*/ -/* */ -/*-*/ -/* */ -/* Description: */ -/* */ -/*-*/ -/* */ -/* Code */ -/* References: RTEMS MBX8xx PCMCIA IDE harddisc driver */ -/* Module: pcmcia_ide.c*/ -/* Project: RTEMS 4.6.0pre1 / Mbx8xx BSP*/ -/* Version */ -/* Date: 01/14/2003 */ -/* */ -/* Author(s) / Copyright(s): */ -/* */ -/*Copyright (c) 2003 IMD */ -/* Ingenieurbuero fuer Microcomputertechnik Th. Doerfler */ -/* */ -/* all rights reserved */ -/* */ -/* this file contains the BSP layer for PCMCIA IDE access below the */ -/* libchip IDE harddisc driver based on a board specific driver from */ -/* Eugeny S. Mints, Oktet */ -/* */ -/* 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. */ -/* */ -/*-*/ -/* */ -/* Partially based on the code references which are named above. */ -/* Adaptions, modifications, enhancements and any recent parts of*/ -/* the code are under the right of */ -/*
