Re: Outdated list of BSPs in rtems-tools/config
Hello Peter, just my two cents regarding eTPU: NXP has more or less left the PowerPC architecture and favor ARM for automotive applications. But the MPC5xxx controllers were developed in some sort of cooperation with ST microelectronics. And ST is still actively playing with this family. E.g. the SPC564 is still equipped with the eTPU. So the legend lives on ;-) wkr, Thomas. Am 14.09.23 um 21:22 schrieb o...@c-mauderer.de: Hello Peter, Am 13.09.23 um 19:22 schrieb Peter Dufault: On Jul 25, 2023, at 10:14 , Joel Sherrill wrote: Most of those are recent and from a lot of different people. GSoC, Kinsey, you, Vijay or Chris, Karel, etc. But I wonder about that phycore_mpc5554. I think it has been around a LONG time. I'm cleaning my in-box, and I missed a reference to te Phycore-MPC5554 BSP in July. I am the one who added the Phycore-mpc5554 as a minor refinement to the Freescale MPC55xx embedded board BSPs developed by "eb". It *is* time to retire the Phytec board as that board is no longer available. But, I hope we can keep it around for a while as I now need to work on a follow-up to that BSP. That thread was not about retiring or deprecating BSPs. It was about some missing BSPs in the rtems-tools/config files. So if it is still necessary, I don't think the BSP should be removed. One of my clients uses the Phycore-MPC5554. They missed the end-of life announcement for that board. They need to quickly update to something very compatible, and a BSP based on the PHYTEC MPC5674F will work, the MPC5674F has all the functionality they require without software changes. I'd like to keep the Phycore-MPC5554 BSP alive and kicking while I develop equivalent MPC5674F support. OK for me. A related question. I think "eb" has a "gwlcfm" target that uses this NXP architecture in one of their products. "eb", are you planning another "gwlcfm", or are you done with that, and what platform would you move to? I'd like to learn about an architecture that works as well as the old Motorola architecture does without custom FPGA programming. I think it's possible that a new batch of the gwlcfm hardware will be manufactured in the next few years. But it's quite unlikely that the software will get an upgrade. The question about a good architecture is quite difficult because it's always quite application specific. For RTEMS work that I do, usually a customer already selected a chip (most of the time some ARM). Therefore, I can't pick a platform that often. For eb-projects, we usually use NXP or ST chips. On the NXP it would be i.MX or now also i.MXRT and for ST it's one of the many STM32 chips. Personally I would like to play a bit with Risc-V chips. But I haven't found any time yet. Additionally, it seems that there are still not that many manufacturers that produce Risc-V chips. If I leave the old Motorola PowerPC's architecture targeted at engine control, I will miss how the ADC DMA chain works together with the eTPU and also schedules the output so cleanly do background motor control, and other timing intensive applications, so that the main CPU is free to e.g. run RTEMS (and in my case position servo control). Difficult. Best bet is some NXP chip because they have quite some peripherals that are still based on the Motorola chips. But I think you know these chips already and it seems that they are not a good enough replacement. Otherwise, you wouldn't ask. At the moment a lot of chips start to provide two different ARM cores. One bigger (often Cortex-A; sometimes multicore) and one smaller one (most of the time Cortex-M). I haven't used both CPUs of these dual CPU systems yet. But in theory they should allow some quite nice division of tasks: The small CPU can handle the timing intensive application (maybe with some bare metal code). The second CPU can handle higher level control and communication. It would be interesting to implement something like that. Best regards Christian Peter - Peter Dufault HD Associates, Inc. Software and System Engineering ___ 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 -- embedded brains GmbH & Co. KG Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49- 89-18 94 741 -12 mobil: +49-176-15 22 06 - 02 Registergericht: Amtsgericht München Registernummer: HRA 117265 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-libbsd freebsd-org submodule would require update in order to import genet drivers. Suggestions?
Hi, if I get things right the update policy of freebsd is currently stuck within the RTEMS community. There are objections regarding the way libbsd has been created/adapted to RTEMS in the past but no real decision how/who would provide/maintain a different way. I think this is a really bad situation. And it doesn't only block work from other volunteers, but also blocks required security updates. I would vote for keeping and using the established way intact as long as we have no alternative accepted, implemented and maintained in the main branch. But this is only my opinion, any others are welcome to speak up. wkr, Thomas. Am 04.06.23 um 17:44 schrieb Noor Aman: Ping, I still require some assistance. Else I'll go by with Kinsey's suggestion as follows: If it turns out we can't trivially bring things up to current, you may need to import the current updated driver from freebsd master into rtemsbsd and maintain it out of tree. Thanks On Thu, 1 Jun 2023 at 23:46, Noor Aman <mailto:nooraman5...@gmail.com>> wrote: Hello, Currently freebsd-org submodule is currently checked out at hash-ID 5d85e12 dated September 24, 2019 in master rtems-libbsd branch. In order to import genet drivers, I need to at least get commit from april 2020. Specifically this one https://reviews.freebsd.org/D24436 <https://reviews.freebsd.org/D24436> In terms of freebsd release numbers, I need freebsd 13.x candidate in order to import genet drivers. There are no drivers for it in freebsd 12.x. From what I have read in the documentation, the working directory needs to be clean in order to start importing process, but i'm unable to do so when switching to main or master branch. What should I do? Any suggestions? Thank you, -- Mohd Noor Aman Tinkering with Hardware ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49- 89-18 94 741 -12 mobil: +49-176-15 22 06 - 02 Registergericht: Amtsgericht München Registernummer: HRA 117265 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] Update company name
Hello Joel, just found time to look up the corresponding US terms. Previously embedded brains was a GmbH, which is comparable with a LLC. Since end of 2022 embedded brains is a GmbH & Co. KG, which is comparable with a combination of LLC and LLP. wkr, Thomas. Am 19.05.23 um 14:32 schrieb Joel Sherrill: These look ok but what does the change to an LLC in English terms mean? On Fri, May 19, 2023, 1:29 AM Sebastian Huber <mailto:sebastian.hu...@embedded-brains.de>> wrote: The embedded brains GmbH & Co. KG is the legal successor of embedded brains GmbH. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH & Co. KG Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49- 89-18 94 741 -12 mobil: +49-176-15 22 06 - 02 Registergericht: Amtsgericht München Registernummer: HRA 117265 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)
Hello, 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. wkr, Thomas. Am 23.01.23 um 14:33 schrieb Christian MAUDERER: 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 ther
Re: Time to promote lwip git repo
Hi, just for the records: I also gratly appreciate this happening. The freeBDS networking capabilities have grwon bigger and bigger, increasing the need for a reduced functionality network stack. Having lwip available allows the user to choose, which package is right for his application. Thank you all for getting this done! wkr, Thomas. Am 19.07.22 um 16:40 schrieb Gedare Bloom: On Wed, Jul 13, 2022 at 11:27 PM Christian MAUDERER wrote: Am 13.07.22 um 04:51 schrieb Chris Johns: On 13/7/2022 10:08 am, Joel Sherrill wrote: Vijay and Kinsey have made great progress in addressing the issues that were raised about the lwip tcpip stack that needed to be addressed before it became an official top level repository. Thanks to both of them. Well done. Great effort. I think it's time to promote the repo. Hopefully just a couple of core developers agreeing is sufficient to get this moving. I support this happening. It is great to see this networking option for small devices become available. I haven't tested the lwip repository yet, but I agree that a stack for small targets is great. So I would support that too. I'm glad to see this happening and support the promotion. Christian -- embedded brains GmbH Herr Christian MAUDERER Dornierstr. 4 82178 Puchheim Germany email: christian.maude...@embedded-brains.de phone: +49-89-18 94 741 - 18 mobile: +49-176-152 206 08 Registergericht: Amtsgericht München Registernummer: HRB 157899 Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler Unsere Datenschutzerklärung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 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: RFC: Copyright vs COPYRIGHT
Hi, I think having this consistent is better. But I don't care about Upper vs. mixed case... Am 26.03.22 um 23:48 schrieb Joel Sherrill: Hi The Software Engineering Guide example uses "Copyright" but a lot of places in the code base use "COPYRIGHT". This is sometimes followed by (c) rather than the (C) indicated in the guide. Any objections to making this consistent? Thanks. --joel ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 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: micro-ros support for RTEMS
Hi Patrick, that sound interesting, I would love to find time playing with it (and some robots)... wkr, Thomas. Am 10.10.21 um 14:04 schrieb Patrick Roncagliolo: Hi everyone, at this link https://github.com/micro-ROS/micro_ros_setup/issues/397 I began to investigate the steps of making micro-ROS compile under RTEMS 5. tl;dr: I wrote a CMake snippet to let the micro-ROS "generate-lib" set of scripts cross compile everything for RTEMS 5. I have not managed to proceed with tests on virtual or real systems, and I seek feedback, but the setup already produces a static library + a set of headers. additional info: For whose of you who don't know ROS (or, more specifically, ROS2), it is a middleware used in robotics to exchange data with publisher-subscriber pattern and offer remote procedure call services over a standardised transport layer (DDS). Micro-ROS is the version adapted to embedded applications, already compatible with various RT-OSes with POSIX interface (alongside a barebone version that targets Arduino). Hoping that this is the right place to share this development, Patrick Roncagliolo Hobbyst / Robotic Engineer @ Thales Alenia Space Italy ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 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-docs] eng: Add rules for attribution
Hi Chris, Am 30.09.21 um 02:23 schrieb Chris Johns: On 29/9/21 6:38 pm, Christian MAUDERER wrote: To be honest: If sponsored work is a legal problem, we have that with or without a note in the files. It's only more visible with a note in the files. I don't think that a legal problem would be avoidable just by not mentioning it. That is not the legal aspect I have in mind. There exists constraints about payments for work done in relation to tax law and this varies around the world. A notice could be taken as evidence. For example a functioning non-profit such as the RTEMS Foundation can accept donations and how that money is spent is up to the foundation. The contributor has no input on that process otherwise it is tax avoidance. This area is strict and the governance is important. I will let you consider the relationship between fair attribution for the whole community and those contributing to a non-profit. Surely this must be considered, but OTOH RTEMS code is definitively a project which combines non-profit and with-profit people to create and maintain code, especially since the birth of the project was with-profit. So if it comes to contributions e.g. from our company: Yes, they are created with profit. Certain areas are handled non-profit. Maybe the question then is, how to properly distinguish them. A foundation wouldn't change the problem discussed here. Don't get me wrong: I would love to see the foundation. But I don't think that the foundation would be the the same as the RTEMS open source project from a legal point of view. It would only be another (much needed) sponsor of work and infrastructure. Sorry, a non-profit does not work that way as I stated above so no attribution can happen. This makes attribution fundamentally unfair. I agree that a "sponsored by RTEMS Foundation" entry wouldn't make sense, because the whole idea of the Foundation is to maintain RTEMS. But, regarding the "sponsored by" entry, I wouldn't talk about fairness. In the past we always had the question "who is using RTEMS" and in many cases had to shrug shoulders because we either don't know or shouldn't tell. If RTEMS user companies officially ask to be visible, I think this is something we should push and not block, right? I have to say I not entirely comfortable with this happening and I will not be encouraging additions. If Thomas wishes to discuss this further I suggest he reaches out to me personally. That makes sense, I will try next week when being back at work. Thomas. Chris ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel -- embedded brains GmbH Herr Thomas DOERFLER Dornierstr. 4 82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de phone: +49-89-18 94 741 - 12 fax: +49-89-18 94 741 - 09 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: Breaking Long Lines
Hi, Am 10.11.20 um 06:33 schrieb Chris Johns: > On 9/11/20 5:50 pm, Sebastian Huber wrote: >> On 09/11/2020 01:52, Chris Johns wrote: >> >>> On 6/11/20 7:11 pm, Sebastian Huber wrote: ... >>> >>> Avoid excess parentheses. Learn the operator precedence. rules. >> >> Yes, and I think this is a good rule. > > I am not sure it is a good rule and workable. Using it to handle indents is an > example of it breaking down. The ability to control an indent is a long held > tradition and editors like Emacs are designed to handle it yet it is not clear > if it is OK under this rule. > I tried not to jump in for more than 24 hours. But now I want to drop in my opinion. What is the whole purpose of a style guide? Is it to have a nice looking code layout, neat an tidy like a ideal front garden, or is it about readability/accessibility? We could write the whole of a C module into one line and it could work anyway, so what about a style guide? IMHO it should improve readability and understanding of what goes on in a certain module. The code should be readable and understandable not only for highly experienced C programmers, but also for newbies (if they trhttps://embedded-brains.de/datenschutzerklaerung/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: BSP maintenance (was Re: set_vector() on SPARC)
Chris, hm, isn't this something related to our tiering of architectures/BSPs? Those who have a maintainer/test board should detect any fault due to the proposed change rather soon/at the next regular test. Those who are not in constant testing... well they are not tier 1, right? wkr, Thomas. Am 20.10.20 um 04:32 schrieb Chris Johns: > If these architectures are not being maintained as you suggest where do we > document this and how do we inform the users? > > If you did update the architectures to remove set_vector are they now > maintained? > > Is updating the code without being able to test the changes maintaining an > architecture or BSP or do we require some level of testing? > -- ---- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Interest in Virtual RTEMS Workshop
Hi Joel, you know I thought about a workshop/conference/meeting some years ago, but the reasons you list in your message exactly hit the problems. So I think such a virtual workshop would be a good idea (wow, thank you, corona! (at least for this)). Presenting what RTEMS is used for, how certain problems got solved, where RTEMS is traveling to... would be interesting. Having some open talks about what the users like (and dislike) at RTEMS, how the future should look... would somehow round it up. And getting/completing a world map, where RTEMS users are located would be nice to see too. wkr, Thomas. Am 02.10.20 um 22:02 schrieb Joel Sherrill: > Hi > > In the past, we have internally discussed an RTEMS Workshop but always > got hung up on the basic logistics. There had to be a host site which > usually means cost. Although OAR now has access to a facility that could > host about 40-50. Travel required to all be in a central location would > be burdensome based on time and cost. Remember the core developers are > spread across three continents. > > The pandemic has made it clear that virtual meetings, conferences, > birthday parties, etc. are possible. Based on ideas from other open > source projects, I am curious if there would be interest in having a > virtual workshop. > > One thought is that given the time zones, it might be nice to do it as a > TBD number of 2-3 hour sessions which vary in time across 2-3 days. That > should let different people participate. One open source project did a > 24 hour event which spanned the world. I do not want to do that. :) > > I think recording the presentations beforehand and making them available > afterwards would be ideal. I have seen formal setups where questions are > restricted to the end of the presentation but like the idea of the > presenter able to chat while their presentation is going. > > In my perfect world, most presentations would be from people using > RTEMS, although I expect core developer presentations would add depth to > what they are working on and the goals. > > Is there interest? Would you be willing to present? participate? Advice? > > Thanks. > > --joel > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: We are loosing patches
Hi Joe, just a brief note from holidays: Am 09.09.20 um 15:19 schrieb Joel Sherrill: > All system administration on rtems.org <http://rtems.org> is volunteer. > That by itself is the > biggest barrier. We've talked collecting funds through a foundation. How can we push that to at least partly professionalize the administration? IMHO we are stuck with "I want to do X when I find proper time for it". Collecting (constant?) funds may solve this a bit. Other open source projects made this move quite successfully. wkr, Thomas. > > --joel > > Ph > Best regards, > > Jan > > > -Original Message- > > From: devel <mailto:devel-boun...@rtems.org>> On Behalf Of Christian Mauderer > > Sent: Wednesday, September 9, 2020 10:24 AM > > To: RTEMS Devel RTEMS mailto:devel@rtems.org>> > > Subject: We are loosing patches > > > > Hello, > > > > triggered by a comment from Chris here > > > > https://lists.rtems.org/pipermail/users/2020-September/067873.html > > > > I started to take a look at patches from non maintainers and write > after > > approval maintainers for some months: I think in May and June we > lost at > > least one or two of the following ones: > > > > https://lists.rtems.org/pipermail/devel/2020-May/059751.html > > https://lists.rtems.org/pipermail/devel/2020-May/059771.html > > https://lists.rtems.org/pipermail/devel/2020-May/059772.html > > https://lists.rtems.org/pipermail/devel/2020-May/059773.html > > https://lists.rtems.org/pipermail/devel/2020-June/060125.html > > https://lists.rtems.org/pipermail/devel/2020-June/060231.html > > https://lists.rtems.org/pipermail/devel/2020-June/060235.html > > > > It's a bit hard to see exactly whether a later version has been > added with a > > different subject, merged with another patch or just has been > rejected for > > some reason. That's another problem with our current system. > > > > I think we start to loose valuable contributions due to that. I > also found some > > patches where just no one responded because no one noted it and the > > person sending the patch had to ping it some time later. That's > not really > > encouraging to continue participating for new contributors. > > > > I even lost track of some of my own patches in the past and found > out about > > a month later that I should have pushed them long ago. > > > > Maybe it would be a good idea to start at least discussing whether > we should > > change something to avoid these problems. I think our current > system has > > two main problems: > > > > 1. All patches go to one single devel mailing list. It's sometimes > hard to see > > which patches are for what repository. And small patches tend to > just vanish > > between lot of other mails. > > > > 2. We have a big problem seeing which patch sets are done, which > are in the > > middle of a discussion and which are rejected. > > > > A lot of other projects use software to solve these problems. > Linux uses > > "patchwork" for it since a long time (which needs one mailing list per > > project). Most other projects use systems with pull requests like > github or a > > self hosted gitlab for that kind of stuff. > > > > Maybe we should think about following these examples and go one > step to > > more modern software development too? What do you think? > > > > Best regards > > > > Christian > > -- > > > > embedded brains GmbH > > Herr Christian Mauderer > > Dornierstr. 4 > > D-82178 Puchheim > > Germany > > email: christian.maude...@embedded-brains.de > <mailto:christian.maude...@embedded-brains.de> > > Phone: +49-89-18 94 741 - 18 > > Fax: +49-89-18 94 741 - 08 > > PGP: Public key available on request. > > > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > _______ > > devel mailing list > > devel@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > ___ > devel mailing lis
Re: SPDX License Identifier Only and Full Copy?
+1 from me. Am 21.02.20 um 15:26 schrieb Sebastian Huber: > > My main goal is to have a foolproof file template for all our source > files very soon. > > Linux has the policy to put the SPDX at the first line if possible. The > only exception are scripts which need an interpreter line for the shell > (2. Style): > > https://www.kernel.org/doc/html/latest/process/license-rules.html > > Maybe we can use this policy in RTEMS as well (except for third-party > code of course). > > We can keep the BSD-2-Clause text in the file. We can also keep the > @file on the top. Example: > > /* SPDX-License-Identifier: BSD-2-Clause */ > > /** > * @file > * > * @ingroup RTEMSApplicationConfiguration > * > * @brief Evaluate Configuration Options > * > * This header file includes a couple of header files which evaluate the > * configuration options specified by the application. The macros and > defines > * used to configure the system are documented in the Configuring a System > * chapter of the Classic API User's Guide. > */ > > /* > * Copyright (C) 2020 embedded brains GmbH (http://www.embedded-brains.de) > * Copyright (C) 1989, 2000 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. > */ > > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SPDX License Identifier Only and Full Copy?
Hello, I think the GPL and the BSD licenses had a different approach from the start: - GPL always came with a separate "COPYING" file (and the GPL sources pointed to it) - BSD always/most of the times was included in the headers Lokking at how the linux kernel team handles this therefore only has a limited weight. So I tend to keep the BSD license text in the source code files. Keep in mind: We want to make sure the license topic is properly handled and clear. What is the harm to be conservative here and spend some extra lines of header in the files? Kind regards, Thomas. Am 21.02.20 um 02:15 schrieb Chris Johns: > > > On 21/2/20 12:11 pm, Joel Sherrill wrote: >> >> >> On Thu, Feb 20, 2020, 3:49 PM Chris Johns > <mailto:chr...@rtems.org>> wrote: >> >> On 21/2/20 3:20 am, Gedare Bloom wrote: >> > On Thu, Feb 20, 2020 at 12:58 AM Thomas Doerfler >> > > <mailto:thomas.doerf...@embedded-brains.de>> wrote: >> >> >> >> Hello, >> >> >> >> I just want to speak up here. I talked with Sebastian today and I >> really >> >> tend to keep the license text in each file. >> >> >> >> Rational: >> >> >> >> - With the BSD license, anyone can pick any file from the RTEMS repo >> and >> >> use/modify it in any project (and this is fine). The original authors >> >> (and their copyright) are listed in the file, but the only pointer to >> >> the legal part is the "SPDX identifier". I am not sure whether this >> is a >> >> legally binding "tag" and whether this tag is clear to any user. >> >> >> >> - Strictly seen, it is not even forbidden to remove the "SPDX >> >> identifier", because it is not part of the BSD-2-clause-license, it's >> >> just a pointer to it. In the end we might result in code drifting >> around >> >> without license information, which we all do not want to see. >> >> >> > This is a valid point. I also have no desire to be a lawyer. >> > >> > My intuition here is that, even without any licensing information at >> > all in individual files, one can still apply a single license to an >> > entire repository, e.g., BSD or GPL. For historical reasons, and >> > similar arguments as you've made, BSD-style licenses have tended to be >> > copy-pasted to individual files to make them easier to excerpt. We >> > don't have license uniformity, so we do need to individually specify >> > which license(s) apply to each file. >> >> This makes sense. The simplified BSD license states ... >> >> 1. Redistributions of source code must retain the above copyright >> notice, this list of conditions and the following disclaimer. >> >> I do not see how we can centralise this and have the "above copyright" >> work? >> Also the SPDX site here ... >> >> https://spdx.org/ids-how >> >> ... under the heading "Standard license headers" states ... >> >> When a license defines a recommended notice to attach to files >> under that license (sometimes called a "standard header"), the SPDX >> project recommends that the standard header be included in the files, >> in addition to an SPDX ID. >> >> My reading of this means we should include the license in the source. >> >> We need to consider compliance and machine auditing of the source. The >> SPDX tag >> is important. Maybe ... >> >> /* >> * SPDX tag suff >> */ >> /* >> * Copyright stuff >> * >> * 2-Clause BSD license >> */ >> >> > Linux follows a similar philosophy as Sebastian suggests. I think we >> > can also follow Linux in this regards. >> > https://www.kernel.org/doc/html/latest/process/license-rules.html >> > >> > I would suggest we follow their approach to self-document the licenses >> > centrally. I suspect the risk of someone using code without adhering >> > to the license is no greater. Probably they have a higher risk >> > exposure than we do! >> >> I agree with the comments in the Linux license rules text about license >> text in >> files making it harder to check for compliance. >> >> >> Following Linux is probably a safe approach. I assume there was significant >> legal review of their policy. > > Does the Linux kernel rules apply to the 2 clause BSD license we have? > > Chris > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: SPDX License Identifier Only and Full Copy?
Hello, I just want to speak up here. I talked with Sebastian today and I really tend to keep the license text in each file. Rational: - With the BSD license, anyone can pick any file from the RTEMS repo and use/modify it in any project (and this is fine). The original authors (and their copyright) are listed in the file, but the only pointer to the legal part is the "SPDX identifier". I am not sure whether this is a legally binding "tag" and whether this tag is clear to any user. - Strictly seen, it is not even forbidden to remove the "SPDX identifier", because it is not part of the BSD-2-clause-license, it's just a pointer to it. In the end we might result in code drifting around without license information, which we all do not want to see. As you all know I am not a lawyer (and don't want to be), but my gut say's the extra lines in the top of each file are worth their storage. And anybody opening a RTEMS source file (even when it has been taken to a different project) should see what he has. - If you have different reasons to replace the header and just leave the identifier I a will go with it and it's fine for me. But my tendency is... leave it in. Kind regards, Thomas. Am 20.02.20 um 08:30 schrieb Sebastian Huber: > Hello, > > On 18/02/2020 16:58, Gedare Bloom wrote: >>>>> I suggest to use a master COPYING file and use file headers without >>>>> the >>>>> full license text. >>>>> >>>>> https://lists.rtems.org/pipermail/devel/2018-December/024198.html >>>> It would be nice to get some feedback here. >>> >>> I'm generally ok with just the spdx and copyright statements. >>> >> I'm also fine with the master COPYING, spdx-tag, and individual >> copyrights in files. >> >> I should make a note to take a pass over "my" files to relicense them. >> Does anyone have any script/tools for making that easy? > > I talked with Thomas and he is not in favour of a removal of the licence > text. Not everyone knows what an SPDX-Licence-Identifier is and that > this means the file is covered by the reference license. The > BSD-2-Clause license text is quite clear and not long. For us it is > important that it is very clear that our contributions are without > warranties and so on. This information should be also clear if files are > transferred out of the RTEMS context to other projects. > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tiering, Expected Failures, and BSPs which Run on Multiple Sims/HW
Joel, it all comes down to "where was it tested". Knowing a certain test works on ONE architecture, on ONE member of a BSP family never means it works on all. Surely if it fails on one member it makes other members's support suspicious, but the result is always for the hardware/simulator it ran on. If a BSP covers various variants and boards/simulators, you must test it on all variants to find out whether they work. OTOH, if a BSP at least succeeds on one supported HW, it is worth keeping it actively in the tree. So I still think that we should track test results per arch.bsp.variant.HW, not only per arch.bsp And we should apply the tiering scheme to the HW, not only the BSP. But, yes, it's hard. Thomas. > > The tester makes a distinction (e.g. leon3-sis vs leon3-tsim or > leon3-qemu) but they > all test the same binaries with different results. The set of expected > failures on each > of those could be different. > > I don't have a good answer. We currently think of three levels: > > + architecture > + BSP Family > + BSP Variant > > and now we are adding the "what did we run that test on" variant for > record keeping purposes > > AFAIK The current .tcfg files control only the set of tests that would > be considered permanent > failures across all "runner" variants. > > This is just hard. :( > > --joel > > > > Kind regards, > > Thomas. > > > > > ___ > > devel mailing list > > devel@rtems.org <mailto:devel@rtems.org> > > http://lists.rtems.org/mailman/listinfo/devel > > > > -- > > embedded brains GmbH > Thomas Doerfler > Dornierstr. 4 > D-82178 Puchheim > Germany > email: thomas.doerf...@embedded-brains.de > <mailto:thomas.doerf...@embedded-brains.de> > Phone: +49-89-18 94 741-12 > Fax: +49-89-18 94 741-09 > PGP: Public key available on request. > For our privacy statement, see > https://embedded-brains.de/en/data-privacy-statement/ > _______ > devel mailing list > devel@rtems.org <mailto:devel@rtems.org> > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Tiering, Expected Failures, and BSPs which Run on Multiple Sims/HW
Hi, Am 25.10.19 um 16:08 schrieb Joel Sherrill: > > One question we need to discuss is what about BSPs which can run on > multiple simulators and possibly real hardware. For example, the sparc > BSPs can run on real hardware, sis, qemu, and tsim. How do we > distinguish the same BSP's expected results on > 1 platform? if I remember correctly, those BSPs targetting for multiple boards/simulators only have a limited number of target boards. Could we consider each (reference) target board and/or simulator instead of a BSP? The tiering may then be for a board instead of a BSP. And the BSP tier is best tier of the target boards? Kind regards, Thomas. > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- -------- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. For our privacy statement, see https://embedded-brains.de/en/data-privacy-statement/ ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: xilinx_zynq_zc702 vs. xilinx_zynq_zc706 memory map
Hi,
most likely the RAM areas have been mapped to the lowest-possible
non-NULL address, and they can be mapped to an address boundary matching
the RAM size. zc702 has a 1MByte ram, mapped to the 1MByte boundary,
zc706 has a 4MByte RAM mapped to the 4MByte boundary.
Having an identical starting address for all possible zynqs would mean to
- identify the biggest ever possible RAM size
- modify the zynq initialization for all boards.
Do we have a problem with the different starting addresses?
wkr,
Thomas.
Am 23.10.19 um 13:47 schrieb Sebastian Huber:
> Hello,
>
> why is the ZYNQ_RAM_ORIGIN different in these two BSP variants?
>
> AS_IF([test "x${RTEMS_BSP}" == xxilinx_zynq_zc702],
> [ZYNQ_RAM_ORIGIN="0x0010"
> ZYNQ_RAM_MMU="${ZYNQ_RAM_ORIGIN}"
> ZYNQ_RAM_MMU_LENGTH="16k"
> ZYNQ_RAM_ORIGIN_AVAILABLE="${ZYNQ_RAM_ORIGIN} + 0x4000"
> ZYNQ_RAM_LENGTH_AVAILABLE="${BSP_ZYNQ_RAM_LENGTH} - 1M - 16k"
> ZYNQ_RAM_INT_0_ORIGIN="0x"
> ZYNQ_RAM_INT_0_LENGTH="64k + 64k + 64k"
> ZYNQ_RAM_INT_1_ORIGIN="0x"
> ZYNQ_RAM_INT_1_LENGTH="64k - 512"])
>
> AS_IF([test "x${RTEMS_BSP}" == xxilinx_zynq_zc706],
> [ZYNQ_RAM_ORIGIN="0x0040"
> ZYNQ_RAM_MMU="${ZYNQ_RAM_ORIGIN}"
> ZYNQ_RAM_MMU_LENGTH="16k"
> ZYNQ_RAM_ORIGIN_AVAILABLE="${ZYNQ_RAM_ORIGIN} + 0x4000"
> ZYNQ_RAM_LENGTH_AVAILABLE="${BSP_ZYNQ_RAM_LENGTH} - 4M - 16k"
> ZYNQ_RAM_INT_0_ORIGIN="0x0000"
> ZYNQ_RAM_INT_0_LENGTH="64k + 64k + 64k"
> ZYNQ_RAM_INT_1_ORIGIN="0x"
> ZYNQ_RAM_INT_1_LENGTH="64k - 512"])
>
--
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
For our privacy statement, see
https://embedded-brains.de/en/data-privacy-statement/
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
Re: OAR Grants Permission to Relicense Its RTEMS Contributions to 2-Paragraph BSD
Hi Joel, it took some time, but today I will send you a set of agreements from our embedded brains team via PM. Kind regards, Thomas. Am 07.08.18 um 23:21 schrieb Joel Sherrill: > Hi > > I have attached a letter (PDF) to ticket 3053 > (http://devel.rtems.org/ticket/3053) from On-Line Applications > Corporation (OAR) which grants the RTEMS Community permission to > relicense our current and future contributions. The text of the letter > is as follows: > > ''On-Line Applications Research Corporation (OAR) grants permission to the > RTEMS Foundation to relicense its current and future contributions from > our current license GPLv2 plus exception to the RTEMS license becoming the > 2-Clause BSD License (https://opensource.org/licenses/BSD-2-Clause > <https://opensource.org/licenses/BSD-2-Clause>). OAR > shall work with the RTEMS Foundation to facilitate this change in the > license as soon as possible.'' > > We encourage other contributors to do the same so the relicensing effort > can proceed. > > Thanks. > > --joel > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
importing selected (dual license) linux modules
Hi, in the past few months, Sebastian has extended the RTEMS libbsd infrastructure so it technically can import/export modules from/to the Linux kernel tree. This extension is quite delicate, because in general, the Linux kernel sources are published under GPLv2, which is definitively incompatible with the RTEMS license. But there are some modules, which are dual licensed (GPLv2 or BSD style), and for those, this extension would be useful. In fact, this extension has been created to import (and stay in sync with) the DPAA infrastructure for the FSL/NXP QorIQ device family. Background (can be skipped): in the past, Sebastian has created the libbsd infrastructure to import various SW modules from FreeBSD. This allows us to use FreeBSD code for networking, USB, WLAN and a broad range of drivers in RTEMS. The infrastructure allows the RTEMS project to stay in sync with FreeBSD. This means e.g. that we can harden the WLAN/WPA2 implementation against the "KRACK" attack as soon as a patch is available for FreeBSD. Now we have a delicate libbsd extension requirement: RTEMS contains support for the FSL/NXP "QorIQ" device family, which has 24(!) processors integrated and currently forms the upper end of RTEMS multicore BSPs. This chip family has a networking subsystem "DPAA" with complex communication/routing/switching capabilities, including multiple 10GBit ethernet interfaces. Writing a networking driver for this beast is virtually impossible due to its complexity. Using/integrating NXPs DPAA framework is the only feasible way to support these interfaces. The framework is published and maintained(!) inside the linux kernel code, and it is released under a dual (GPL or BSDish) license. -- Now I see four ways to deal with this linux importer: A.) We can simply integrate it into RTEMS as an extension to libbsd. - Technically, it adds a tool to extend the RTEMS code basis. - But Developers, who are not so familiar with licensing issues might easily use it to integrate pure GPLv2 code, which would be a big problem for RTEMS users. B.) We can reject any code (even dual licensed) that is part of the Linux kernel. - This would be inconsistent with other dual licensed modules which are now also part of RTEMS. - In the longer term it would also let the QorIQ support become obsolete (which currently has an important function to prove the superior SMP efficiency of RTEMS). - Maybe this decision would even indicate that the RTEMS project is not capable of keeping track with bleeding edge computing challenges. (I regard this argument a bit disproportionate, but think about it anyway...) C.) We can accept selected linux kernel code (which has a proper dual license) but reject the linux importer mechanism. - This would allow us to carefully integrate interesting modules and make licensing problems less probable. - But this would lead to potential bit rot in these imported modules, a situation we overcame with the libbsd framework. D.) We can accept the linux importer and selected linux kernel code, and provide some monitoring mechanism to avoid misuse of the importer. - This needs extra effort for the monitoring (manually of automatically) - OTOH this would give us more flexibility. --- Any opinions on that? Any hints or ideas how we could solve the discrepancy between flexibility requirements and legal requirements of the project? I would be happy to have this discussed here! Thomas. -- ---- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Time to register: class "RTEMS Application Development" in Munich/Germany, 27.-29. November 2017
Hello, the registration deadline is close: we are planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on November 27th, 2017. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. IMPORTANT: Registration period ends on October 27th, 2017, seats will be assigned on a first come, first serve policy. So now it's time for your registration! wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
REMINDER: class "RTEMS Application Development" in Munich/Germany, 27.-29. November 2017
Hello, just brief reminder: we are planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on November 27th, 2017. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ANN: class "RTEMS Application Development" in Munich/Germany, 27.-29. November 2017
Hello, we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on November 27th, 2017. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 答复: 答复: 回复： GSOC 2017 Beagleboard BSP projects
t;>>> >>>>> What conflicts do you foresee? And can you work with the student >>>>> to avoid or minimize them. >>>>> >>>>> Working in the open and coordinating efforts is critical in any open >>>>> source project. This seems like one which can be managed. Especially >>>>> if you help out on this project so you can help avoid the issues. >>>>> >>>>> Thanks. >>>>> >>>>> --joel >>>>> >>>> >>>> Hello Joel, Hello Sichen Zhao, >>>> >>>> I agree, that most of the proposal won't be touched by the WLAN part >>>> that is already done or will be (hopefully) done in the near future. I'm >>>> not sure what WLAN chip set is used on the BB (or on the intended USB >>>> dongle) so currently I can't say for sure whether it is already build >>>> with the rest of the drivers or not. Sichen Zhao: Do you have any >>>> information on that? >>>> >>>> A potential conflict in the proposal is in the "Project Deliverables" >>>> the part "August 29-September 5 (Final Evaluation) - Add the wireless >>>> protocol such as 802.11". That is also mentioned in "June 27 - August 23 >>>> (Second Half)" under the point "5.Adding the wireless protocol 802.11 on >>>> RTEMS." >>>> >>>> But to be honest: It might anyhow would have been a quite big workpiece >>>> if it would have been only a part of a GSoC project. The unencrypted >>>> WLAN port has been quite some effort and there is a big part necessary >>>> for the encrypted WLAN user space (the wpa supplicant). So it quite >>>> likely is better to concentrate on the device specific driver and try to >>>> get it running with unencrypted WLAN. If that works, it shouldn't be a >>>> big problem to get the encrypted one running. >>>> >>>> If there is time left for any work: For the encrypted WLAN, it is always >>>> interesting if there is any hardware encryption support. If the WLAN >>>> chip doesn't have it itself (not all USB chips have it), a hardware >>>> encryption of the host processor might be useful. So if the processor on >>>> the BB has a hardware encryption module, it could be nice to have it >>>> supported by the rtems-libbsd. But I'm not sure whether we already have >>>> any encryption on other platforms and I'm also not sure how much work >>>> that would be. >>>> >>>> Please note that I don't really have any experience what the usual scope >>>> is for a GSoC project. So I'm not sure whether that would be possible or >>>> realistic in the given time. >>>> >>>> Kind regards >>>> >>>> Christian Mauderer >>>> -- >>>> >>>> embedded brains GmbH >>>> Christian Mauderer >>>> Dornierstr. 4 >>>> D-82178 Puchheim >>>> Germany >>>> email: christian.maude...@embedded-brains.de >>>> Phone: +49-89-18 94 741 - 18 >>>> Fax: +49-89-18 94 741 - 08 >>>> PGP: Public key available on request. >>>> >>>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>>> ___ >>>> devel mailing list >>>> devel@rtems.org >>>> http://lists.rtems.org/mailman/listinfo/devel >>> >>> -- >>> >>> embedded brains GmbH >>> Christian Mauderer >>> Dornierstr. 4 >>> D-82178 Puchheim >>> Germany >>> email: christian.maude...@embedded-brains.de >>> Phone: +49-89-18 94 741 - 18 >>> Fax: +49-89-18 94 741 - 08 >>> PGP: Public key available on request. >>> >>> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. >>> ___ >>> 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 > > -- > > embedded brains GmbH > Christian Mauderer > Dornierstr. 4 > D-82178 Puchheim > Germany > email: christian.maude...@embedded-brains.de > Phone: +49-89-18 94 741 - 18 > Fax: +49-89-18 94 741 - 08 > PGP: Public key available on request. > > Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. > > > ___ > devel mailing list > devel@rtems.org > http://lists.rtems.org/mailman/listinfo/devel > -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
New class "RTEMS Application Development" in Munich/Germany, May3-5, 2017
Hello, we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on May 3, 2017. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Now it is time to register. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. BTW: The registration period closes on April 12. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
REMINDER: New class "RTEMS Application Development" in Munich/Germany, 18.-20. October 2016
Hello, just a short reminder after the holiday season for those interested: we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on October 18th, 2016. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. There are still a limited number of seats available, so now it is time to register. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. BTW: The registration period closes on October 4th. There is still a limited number of seats left, which will be assigned on a first-come first-serve policy. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
mx6ulevk BSP was: Re: [PATCH] arm: mx6ulevk: Initial BSP support for i.MX 6UltraLite EVK board.
gmail.com>
> + *
> + * Copyright (c) 2013 embedded brains GmbH. All rights reserved.
> + *
> + * embedded brains GmbH
> + * Dornierstr. 4
> + * 82178 Puchheim
> + * Germany
> + * <i...@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.com/license/LICENSE.
> + */
> +
> +#include
> +
> +void bsp_reset(void)
> +{
> + while (true) {
> +/* TODO */;
> + }
> +}
> diff --git a/c/src/lib/libbsp/arm/mx6ulevk/startup/bspstart.c
> b/c/src/lib/libbsp/arm/mx6ulevk/startup/bspstart.c
> new file mode 100644
> index 000..8ebd187
> --- /dev/null
> +++ b/c/src/lib/libbsp/arm/mx6ulevk/startup/bspstart.c
> @@ -0,0 +1,25 @@
> +/*
> + * Copyright (c) 2016 Peng Fan <van.free...@gmail.com>
> + *
> + * Copyright (c) 2013 embedded brains GmbH. All rights reserved.
> + *
> + * embedded brains GmbH
> + * Dornierstr. 4
> + * 82178 Puchheim
> + * Germany
> + * <i...@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.com/license/LICENSE.
> + */
> +
> +#include
> +#include
> +#include
REMINDER: New class "RTEMS Application Development" in Munich/Germany, 18.-20. October 2016
Hello, just a short reminder for those interested: we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on October 18th, 2016. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. There are still a limited number of seats available, so now it is time to register. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. BTW: The registration period closes on October 4th, but we would be happy for an early indication who is interested to participate, so we can estimate the required number of seats. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel ___ users mailing list us...@rtems.org http://lists.rtems.org/mailman/listinfo/users -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
New class "RTEMS Application Development" in Munich/Germany, 18.-20. October 2016
Hello, we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on October 18th, 2016. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. There are still a limited number of seats available, so now it is time to register. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. BTW: The registration period closes on October 4th. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
REMINDER: RTEMS@embedded world2016: Meeting with Chillout Hour
Hi, a short reminder for those interested... And two additional remarks: - unfortunately Joel will not be present in Nuremberg :-( - and I forgot the exact time for the RTEMS Chillout Hour: it is planned for Wednesday, 24.2.2016, 16:30. We should take the opportunity to also drink to Joel's health ;-) Looking forward to seeing many of you, Thomas. --- just to let anyone know: RTEMS@embedded world === The embedded brains GmbH will be present at the "embedded world 2016" trade show in Nuremberg, Germany, which is opened from February 23 'til February 25 2016, see: http://www.embedded-world.de One major topic on our stand 538 in hall 4 will be RTEMS. RTEMS Chillout Hour === For the first time a "RTEMS Chillout Hour" takes place, the idea is to meet and discuss all kinds of RTEMS topics. You provide the discussions, we provide the cocktails ;-) Who is present? === Apart from the embedded brains team, Joel Sherrill from OAR will once again be present. I think this is a good opportunity to meet face to face. We are looking forward to meet many RTEMS users during these days. If anyone is interested in free tickets, please contact me privately. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschÀftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ANN: RTEMS@embedded world2016: Meeting with Chillout Hour
Hi, just to let anyone know: RTEMS@embedded world === The embedded brains GmbH will be present at the "embedded world 2016" trade show in Nuremberg, Germany, which is opened from February 23 'til February 25 2016, see: http://www.embedded-world.de One major topic on our stand 538 in hall 4 will be RTEMS. RTEMS Chillout Hour === For the first time a "RTEMS Chillout Hour" takes place, the idea is to meet and discuss all kinds of RTEMS topics. You provide the discussions, we provide the cocktails ;-) Who is present? === Apart from the embedded brains team, Joel Sherrill from OAR will once again be present. I think this is a good opportunity to meet face to face. We are looking forward to meet many RTEMS users during these days. If anyone is interested in free tickets, please contact me privately. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschÀftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ANN: New class "RTEMS Application Development" in Munich/Germany, 12.-14. April 2016
Hello, we are currently planning an open RTEMS class "RTEMS Application Development" in Munich/Germany to start on April 12th, 2016. This class has is main focus on application development based on the RTEMS kernel. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: 4.11 Branching
Hi, I am glad 4.11 will be branched soon. from our side, branching is ok. So: Any open items left? Anything we can do to make the branch happen soon? Any chance to do the branch within this week? We have held back a set of patches which are too new to be useful for the 4.11 branch. On the other side we would like to commit them soon without spoiling the branch point. wkr, Thomas. Am 30.04.2015 um 16:11 schrieb Sebastian Huber: Hello, is there anything left that prevents us to do the branch now? We can still do some work on the branch before we actually make the release. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RDUC2015 canceled
Hello, my last week's email to speak up for RDUC participation did not generate a great echo, so today we decided to cancel the RDUC2015 conference. It seems the way we prepared the conference did not meet the community requirements and expectations. In the long run I would like to have a regular event where personal contact and discussions are possible, but currently I am not sure which way would be right to organize this. Thank you for all the input we got. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
RDUC2015: Speak up: Participation intended?
Hello, in the past few weeks, we have started preparing the first RTEMS Developers and Users Conference (RDUC). Last Friday, the Early Bird registration period for participation has ended. Unfortunately, up to now the number of registrations is far below our expectations and we currently consider to cancel the event. Before we decide on this, I would like to ask anyone who intends to participate (or at least still has not yet decided) to send a short note to me or r...@rtems.eu. If there is no sufficient feedback 'til next Wednesday (15.4.2015), we will cancel the event. Looking forward to some feedback, Thomas. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
ANN: RTEMS open class in Munich/Germany, 15.-17. June 2015
Hello, we are currently planning another open RTEMS class in Munich/Germany to start on June 15th, 2015. Maybe you or some of your colleagues like to join in? See our updated website http://www.embedded-brains.de/en/rtems-real-time-operating-system/rtems-training-courses/ for more details. Please send us an email or use the website form if you and/or your colleagues are interested to attend, so we can reserve seats for you. wkr, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Reminder: CFP: RTEMS Developers and Users Conference (RDUC 2015)
Hello, just a reminder for all of you interested: There is still some time left to prepare submissions for the RDUC planned from 18.-19. June 2015 in Munich/Germany. Anyway it would helpduring preparations, when those of you interested in presenting their work would give us an early indication. Here is the initial announcement, including one clarification: We do not necessarily expect a formal paper, any useful submission or presentation is welcome. - This is a Call For Papers for the RTEMS Developers and Users Conference (RDUC 2015) which will take place in Munich, Germany from 18.-19.June 2015. (see also: https://www.mail-archive.com/devel@rtems.org/msg02583.html ). We consider this conference as a good opportunity to share ideas, concepts, to present skills and solutions as well as products based on RTEMS. So we are looking for presentations that fit into this format. If you or your colleagues are willing to be a presenter on this conference, please contact us early at r...@embedded-brains.de And here are the details: Topics == Expected contributions include (but are not limited to) the following topics: - best practices for RTEMS - RTEMS-SMP support: present and future - development, debugging and profiling tools and methods - in-system diagnosis - case studies and applications with RTEMS: challenges, problems and solutions - SMP/multicore aspects - platforms for RTEMS - distributed, fail safe systems - energy vs. performance optimization - formal methods for verification - safety and security challenges and solutions Submissions and publication === - Presentations should be passed in in slides, preferably in PDF, LibreOffice or Powerpoint format. - Papers should not exceed 6 pages (Din A4 preferred) and should be handed in in PDF format. All accepted papers/presentations will be published in the conference proceedings and the conference website. Language for all submissions and presentations is English. Important dates: - First Call for Papers/Presentations: Friday, 6. February 2015 - Abstract Deadline: Monday, 13. April 2015 - Acceptance Notification: Friday, 17. April 2015 - Conference: Thursday/Friday 18.-19. June 2015 Orga Team = The embedded brains RTEMS team will organize this conference, so if you have any questions or suggestions, please feel free to contact us by email: r...@rtems.eu A final note: if you intend to hand in a presentation/paper, we be happy to get an early announcement, just to coordinate the topics ASAP. Looking forward to interesting submissions, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Early bird registration open: RDUC RTEMS Developers and Users Conference
Hello Dominik,
I understand that the registration fee is not cheap. We have tried to
keep the costs low, but on the other hand do not have a spare budget to
sponsor the conference. Compared to similar events the fee doesn't seem
unreasonable.
Nevertheless I would be looking forward to seeing you. If not this time,
maybe the next year at your location? ;-)
Kind regards,
Thomas.
Am 02.03.2015 um 17:39 schrieb Dominik Taborsky:
Hello,
I was looking forward to meeting people around RTEMS, but 590 (510)
Euros? Is there an extra zero? Is that how much a usual conference
costs? I could do my own conference for that...
Best regards,
Dominik
On 03/02/2015 03:22 PM, Thomas Doerfler wrote:
Hello,
in January I have announced the 1st RTEMS Developers and Users
Conference (RDUC) to take place in the area on Munich, Germany. The date
is now fixed for the 18.-19. June 2015.
See more details about the conference at:
http://www.embedded-brains.de/en/event/rduc-conference/
The registration form is open now, so if you want to participate, please
register at:
http://www.embedded-brains.de/en/registration-for-rduc/
Please note that the number of seats is limited! Registering within the
early bird period ('til 9, April 2015) will make sure you get a
remarkable discount on the registration fee.
For any questions, please feel free to contact us at
r...@rtems.eu
We will keep this list informed while we proceed with our plannings.
With kind regards,
Thomas Doerfler.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
--
embedded brains GmbH
Thomas Doerfler
Dornierstr. 4
D-82178 Puchheim
Germany
email: thomas.doerf...@embedded-brains.de
Phone: +49-89-18 94 741-12
Fax: +49-89-18 94 741-09
PGP: Public key available on request.
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
___
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
ANN: RDUC RTEMS Developers and Users Conference
Hello, today I want to announce a planned event for June 2015: The First RTEMS Developers and Users Conference (RDUC). Sharing ideas, problems, solutions and future visions via email and chat is fine for the daily work, but the RTEMS community is now big enough to justify a regular conference event. We are in an early planning stage, but already want to ask you all to save the date! Location The first RDUC will be organized in good old Europe, in the area of Munich, Germany. Schedule This will be a two day event. The exact date is not yet fixed, but will be most likely either 11./12. June or 18./19. June 2015. Audience The conference is intended for - application developers using RTEMS in their systems, - system developers interested in extending RTEMS, - system architects looking for a reliable realtime system, - and solution providers for the ecosystem around RTEMS Sessions The individual sessions are not yet fixed, but a number of topics seem interesting for presentation and discussion, like: - best practices for RTEMS with small memory footprint - RTEMS-SMP support: present and future - debugging RTEMS systems with COTS tools - applications with RTEMS: challenges, problems and solutions - verification and validation: present infrastructure and future requirements - fancy plattforms for RTEMS - distributed, fail safe systems - christmas in June: RTEMS wishlist for the next years Orga Team = The embedded brains RTEMS team will organize this conference, so if: - you want to keep updated on this event - you want to attend the conference - you have ideas and recommendations - you want to present your work please send us an email on r...@rtems.eu We will keep this list informed while we proceed with our plannings. With kind regards, Thomas Doerfler. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: [PATCH] License: add a 2-clause BSD license file, and relicense a sparc64 file
Gedare, I am also confused about mentioning your copyright in the LICENSE.2 file. the patch for lib/libbsp/sparc64/niagara/startup/bspclean.c is fine, it tells you are the originator of this file and you apply License.2 to it. What exactly does your copyright notice in License.2 want to say: - That you are coypright holder of the license text? - That you are (partial) copyright holder of ALL RTEMS source files and they are available under this license? - That you are the copyright holder of SOME RTEMS files and they are available under this license? - That any contribution you added to RTEMS is under this license? IMHO such a global statement, leads to confusion and misinterpretation. I may even make a future relicensing more difficult. I personally would prefer to have the LICENSE.2 file in place (without the Copyright Gedare Bloom statement) and then each file pointing to the corresponding license. wkr, Thomas. Am 08.12.2014 um 20:57 schrieb Gedare Bloom: --- LICENSE.2 | 23 ++ .../lib/libbsp/sparc64/niagara/startup/bspclean.c | 5 + 2 files changed, 24 insertions(+), 4 deletions(-) create mode 100644 LICENSE.2 diff --git a/LICENSE.2 b/LICENSE.2 new file mode 100644 index 000..e85f6bb --- /dev/null +++ b/LICENSE.2 @@ -0,0 +1,23 @@ + +Copyright (C) 2014. Gedare Bloom. + +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 HOLDER OR CONTRIBUTORS BE LIABLE +FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL +DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR +SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER +CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, +OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE +OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. diff --git a/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c b/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c index 88750aa..6c622b6 100644 --- a/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c +++ b/c/src/lib/libbsp/sparc64/niagara/startup/bspclean.c @@ -1,10 +1,7 @@ /* * Copyright (c) 2014 Gedare Bloom. * - * 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's license is 2-clause BSD as in this distribution's LICENSE.2 file. */ #include bsp.h #include bsp/bootcard.h -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: Proposed RTEMS Community Code of Conduct
Ralf, I agree that a Community Code of Conduct might be formulated that enables it to be used as a means of oppression. But we are talking about a certain recommended document code. Reading it I do not see any request which seem inappropriate. And breaking the code would not mean to be silently thrown out of the community, it would just start a discussion on staying within reasonable behaviour. So, can you clarify, noting the parts in Joel's recommended RTEMS Code of Conduct, which you fear to be used sa a means of oppression? If I look at the chapter headlines and their content, I don't see anything - Be considerate - Be respectful - Be collaborative - Be pragmatic - Support others in the community - Get support from others in the community Which point actually makes you fear something? wkr, Thomas. Am 15.11.2014 17:01, schrieb Ralf Corsepius: On 11/12/2014 08:49 PM, Thomas Doerfler wrote: What I don't understand in your posting: On the one hand you mention, that the topics of the proposed CCoC have never been an issue on the RTEMS list and on the other hand you point out, that other CCoCs on other lists may have made some users leave the list. Experience tells, in longer terms project leaders tend to instrumentalize Code of Conducts as a means of oppression and suppression, just to silence opposition. Do you think one of the porposed CCoC's topics would make people leave this project? Yes, definitely - CoCs endanger people to being banned from lists because of having expressing opions. To not expose themselves to this danger, they often simply do not express their opinions. They implement a climate of uncertainty and fear. This is counterproductive to OSS-projects. OSS-projects need open minds, and needs tolerance - not censorship. I see no harm in the CCoC, and always appreciate clear words. IMO, clear words and a CCoC are self-contractory and mutally exclusive. Ralf -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: mpc8xx BSPs Have Most Warnings Help Request
Joel, we will see to this 'til Wednesday. CU, Thomas. Am 17.10.2014 17:33, schrieb Joel Sherrill: Hi The only BSPs with more than 5 warnings in the BSP specific code are the following: 21 powerpc-mbx821_001 (inBSP=18 inLibCPU=0) 21 powerpc-mbx821_002b (inBSP=18 inLibCPU=0) 21 powerpc-mbx821_002 (inBSP=18 inLibCPU=0) 21 powerpc-mbx860_001b (inBSP=18 inLibCPU=0) 21 powerpc-mbx860_002 (inBSP=18 inLibCPU=0) 21 powerpc-mbx860_1b (inBSP=18 inLibCPU=0) 21 powerpc-pghplus (inBSP=18 inLibCPU=0) 21 powerpc-tqm8xx_stk8xx (inBSgrep P=18 inLibCPU=0) 25 powerpc-mbx860_005b (inBSP=22 inLibCPU=0) Of the 188 unique warnings, 22 are in the mbx8xx BSP and 21 are in the tqm8xx BSP. This is over 20% of the remaining warnings. I would really appreciate it if these warnings could be addressed. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
Re: sleep time is doubled, xilinx_zynq_zedboard
Giovanni, without knowing the BSP: You are talking about CPU clock, the macro is call Periphclk. Can it be that the peripheral bus is clocked with half of the CPU frequency? wkr, Thomas. Am 01.05.2014 12:52, schrieb Giovanni Macciocu: I've made some tests by changing the value of BSP_ARM_A9MPCORE_PERIPHCLK. The value should be 7U as this is my cpu clock speed. However in the following cases #define BSP_ARM_A9MPCORE_PERIPHCLK (2 * 7U) -- a Sleep now takes 4 times as long #define BSP_ARM_A9MPCORE_PERIPHCLK 2 (7U / 2) -- The sleep is now correct In all cases the serial port keeps working at half of the normal buadrate. Regards, Giovanni Giovanni Macciocu g.macci...@sron.nl 5/1/2014 10:53 AM In my bspopt.h /* ARM Cortex-A9 MPCore PERIPHCLK clock frequency in Hz */ #define BSP_ARM_A9MPCORE_PERIPHCLK 7U This is the correct processor speed for my platform. Chris Johns chr...@rtems.org 5/1/2014 10:24 AM t you take a look at the BSPOPTS for the zync BSP. There are some clocks you can set and one of these may help. I think BSP_ARM_A9MPCORE_PERIPHCLK is the one. Chris ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Future of Doc Was: Re: [rtems commit] rtems: Add task get/set scheduler
Hi, good discussion. Maybe it makes sense to define what we want to write into a User's Guide, because the term is used for many different types of documents. I agree with Sebastian that the best place for documenting each API function is doxygen, because it's source is always in sync with the real code (or as close as possible). When it comes to concepts and best practices, when it comes to Getting stared or Write your first RTEMS application, doxygen might not be the best solution. So having an abstract User's Guide that is non-doxygen makes sense to me. It may include: - a Quick Start Guide chapter: hello embedded world in 15 minutes - more details: where do I get all the source code, the toolset, the documentation - RTEMS concepts: APIs, OS objects, threads, memory management, Link strategy, Build strategy, configuration - Best practices: Use confdefs.h, code organization, ... - debugging strategies... The User's Guide should then point to doxygen for the fizzy details. What do you think, does that make sense? wkr, Thomas Am 16.04.2014 16:08, schrieb Gedare Bloom: On Wed, Apr 16, 2014 at 4:08 AM, Sebastian Huber sebastian.hu...@embedded-brains.de wrote: On 2014-04-15 18:20, Joel Sherrill wrote: On 4/15/2014 11:14 AM, Sebastian Huber wrote: On 04/15/2014 02:48 PM, Sebastian Huber wrote: On 2014-04-15 14:36, Joel Sherrill wrote: You added to the API and added no documentation. I added the documentation in Doxygen: http://www.rtems.org/pipermail/rtems-devel/2014-March/005901.html Ok, since we are close to the RTEMS 4.11 release I will add texinfo documentation to all new high-level functions. After the RTEMS 4.11 release we should definitely do something against this copy and paste nightmare. Joel, what is your opinion with respect to the future documentation infrastructure of RTEMS? User Guides should not be in Doxygen. It is possible to write user guides with Doxygen (see @page command). I completely agree that we need to eliminate so much copy-paste. We need to have a better plan for managing documentation, for user developers and for kernel developers. I'd like to hear some more thoughts on the subject and also see some initial requirements. Gedare ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: Patches for Newlib and RTEMS
___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
Re: [GSoC] BAT vs Pages on PowerPC [Please give a feedback]
Chris, Am 23.06.2013 03:46, schrieb Chris Johns: Thomas Dörfler wrote: Note that the pages usually only cover 4K of memory, and the translation lookaside buffer (TLB) only maintains the last 16-64 used pages, The ARM which I am currently using and have handy seems to support 1MB, 64K and 4K ranges depending on the TLB table level used. I would be surprised if an entry was needed for each page in use. Classic PowerPC ist not that flexible. The 603(e) core, that is quite often used in PPC controllers, has a fixed page table entry size of 4K, so the number of TLB entries (the page cache) will never cover the whole lot of pages for a suitable memory size. So for this derivative (and many others) it's Use (statically initialized) BATs or (dynamically reloaded) TLB entries. Thomas. -- embedded brains GmbH Thomas Doerfler Dornierstr. 4 D-82178 Puchheim Germany email: thomas.doerf...@embedded-brains.de Phone: +49-89-18 94 741-12 Fax: +49-89-18 94 741-09 PGP: Public key available on request. Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG. ___ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
