Re: [Discuss] LTS releases
If we focus only on bugfixes and security then there is no concern My coment was mostly related to new boards,drivers and architectures which usually have spread comits On Wed, 12 Feb 2025, 09:27 raiden00pl, wrote: > Nathan, that's not what I mean.Look at this comment from Alin and > discussion > below it: > https://github.com/apache/nuttx/pull/15789#issuecomment-2648017787 > > > wt., 11 lut 2025 o 21:33 Nathan Hartman > napisał(a): > > > There will be regular releases as well and if I am understanding > correctly, > > all PRs that are accepted will go to a regular release, and in addition, > > those that are important bugfixes or security will be backported to the > LTS > > release also. So it's not that PRs would be harder to accept, just that > > we'll be a bit more careful about which ones will be backported to the > > stable, LTS releases. > > > > On Tue, Feb 11, 2025 at 12:46 PM raiden00pl > wrote: > > > > > I personally don't care about LTS releases and it seems to me that > Nuttx > > > doesn't > > > have the resources for it. But if there are people willing to work on > > this > > > this, > > > I wish them good luck. What I don't like is the fact that the new PR > > > requirements > > > for LTS will make life as difficult as possible for contributors. > > > Compensating for > > > lack of resources by making it harder for contributors is the wrong > > > approach. > > > > > > > > > wt., 11 lut 2025 o 15:07 Nathan Hartman > > > napisał(a): > > > > > > > I also think LTS point releases should focus on bugfixes and security > > > only, > > > > to ensure the maximum stability. > > > > > > > > Nathan > > > > > > > > On Tue, Feb 11, 2025 at 8:32 AM Sebastien Lorquet < > > sebast...@lorquet.fr> > > > > wrote: > > > > > > > > > Hello, > > > > > > > > > > I agree. Only bugfixes, criticity threshold to be determined, but > new > > > > > features seem unnecessary to me. > > > > > > > > > > Sebastien > > > > > > > > > > > > > > > On 11/02/2025 12:43, Tiago Medicci Serrano wrote: > > > > > > Hi, > > > > > > > > > > > > I would make the scope even more restricted. Considering an LTS > > > should > > > > be > > > > > > 100% compatible with an existing defconfig, it should not add new > > > > drivers > > > > > > and new HW. I propose it to contain only bugfixes and security > > > patches. > > > > > > > > > > > > Best regards, > > > > > > > > > > > > Em ter., 11 de fev. de 2025 às 08:27, Alin Jerpelea < > > > > jerpe...@gmail.com> > > > > > > escreveu: > > > > > > > > > > > >> I propose that for our first LTS we start with a small scope and > > we > > > > > >> backport only fixes, new hw and drivers > > > > > >> > > > > > >> For the future releases we may consider expanding the scope if > the > > > > > workload > > > > > >> permits > > > > > >> > > > > > >> What do you think ? > > > > > >> > > > > > >> On Tue, Feb 11, 2025 at 10:55 AM Laczen JMS < > laczen...@gmail.com> > > > > > wrote: > > > > > >> > > > > > >>> Hi Alin, > > > > > >>> > > > > > >>> I also encourage this. I would start by defining what is > expected > > > > from > > > > > a > > > > > >>> LTS: > > > > > >>> > > > > > >>> A LTS release of NuttX is a release that will be maintained and > > > > > >>> supported over a longer period of time (1 year). > > > > > >>> LTS updates are mainly focused on bugfixes that where > discovered > > > and > > > > > >>> corrected during the support period. > > > > > >>> These bugfixes will be backported to the LTS release. > > > > > >>> > > > > > >>> Should new features and hardware be allowed in a LTS? If so, > how > > > many > > > > > >>> releases should they have been in? > > > > > >>> Many users will keep there own defconfig for a certain product, > > > > should > > > > > >>> they remain valid? If so are Kconfig changes allowed? > > > > > >>> > > > > > >>> Anyhow thanks for the proposal, > > > > > >>> > > > > > >>> Jehudi > > > > > >>> > > > > > >>> Op di 11 feb 2025 om 10:02 schreef Michael Jung < > > > > > michael.j...@secore.ly > > > > > >>> : > > > > > Hello Alin, > > > > > > > > > > I would love to see this, as it would make maintaining our > > product > > > > > much > > > > > easier. > > > > > > > > > > Thanks for the proposal. > > > > > > > > > > Michael > > > > > > > > > > On Tue, Feb 11, 2025 at 9:55 AM Alin Jerpelea < > > jerpe...@gmail.com > > > > > > > > > >>> wrote: > > > > > > Hi all, > > > > > > > > > > > > there have been suggestions that we should create LTS > releases > > > > > > > > > > > > I propose that we mark every Q1 (match) release as a LTS > > release > > > > and > > > > > > maintain it for 2 years. this would always ensure a fresh LTS > > > > > >>> overlapping > > > > > > the old one and allowing the users to migrate the code to the > > new > > > > > >>> release. > > > > > > What do you think? > > > > > > > > > > > > Best regards > > > > > > Alin > > > > > > > > > > > > > > > > > > > > >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Here goes my vote with too :-P On Tue, Feb 11, 2025 at 12:37 AM Tomek CEDRO wrote: > 1. In Contributing Guidelines we are adding additional section for > Reviewers in order to provide complementary set of rules that should > filter out breaking code as much as possible also on our side. +1: This will also help new reviewers, and keep good standard for everyone. > 2. Each PR (including git commits) _must_ adhere to requirements > presented in Contributing Guidelines or will be auto-rejected until > fixed / updated. +1 > 3. Git commit messages are as important as PR descriptions. These > provide in-code descriptions of each change and are git interface > independent. +1: This is good when we look at git log directly and not the web interface like github. > 4. Proper description of change is mandatory. Description must contain > explanation on what proposed change do, why it is necessary, what if > fixes, and how things are changed / fixed / updated, what is the > impact (build / runtime / api / what area), how it was tested. Local > code build and real world hardware runtime test logs must be provided > where mandatory. Description can be single..several sentences long or > bullet points but enough for anyone to understand change goals and > details. Usually it will look similar for PR and git commit message. +1: Good description is really important. It don't have to be a book, just something that will help other people understand what/why/how/where is changed. This will help reviewers. Big changes will require more information. I see that as general rule for both PR and Git commit descriptions. > 5. Proper description in PR is mandatory, or change is auto-rejected > until fixed / updated. Build and real world hardware runtime logs are > mandatory. +1: If someone develops a code, they need to build and test is anyways, so code changes should require build and runtime logs. For non code changes (i.e. documentation) there are no logs, but something that will prove someone tested stuff locally, maybe this should be clarified. This for sure will prevent situation where someone introduces a change that is not even tested locally and go live testing on ci (that may not catch everything) and other people systems / products. > 6. Proper description in Git commit message is mandatory, or change is > rejected until fixed / updates. Build and runtime logs are optional > here if these are too long and already provided in PR. +1 > 7. Each git commit message must consist of topic, description, and > signature, which are mandatory, or change is auto-rejected until fixed > / updated. Topic consists of functional prefix, ":" mark, and short > self-explanatory context. Description is separated from topic with a > single blank line. Example already presented in Contributing > Guidelines. +1 > 8. Changes must come with with documentation update where applicable. > If change presents new functionality a documentation must be provided > in the same PR (not in future). If change requires documentation > update it must be contained in the same PR (not in future). Successful > documentation build log shortcut is welcome. +1: This is a good rule, people often deliver code and documentation changes which is good, but there are places where documentation is out of sync so this should prevent code-doc desync and update missing docs on code update. > 9. We implement zero trust approach to user provided testing. It is > the commit author duty to provide real world hardware build and > runtime logs that must prove change does not break stuff for others. +1: Strong +1 here, people must realize their changes may impact others, so proper testing is required. We need to also provide tools to make that testing easier (i.e. drunx). > 10. Breaking changes are not welcome. This is anything that alters > Build / Kernel / Architecture / API, alters both nuttx and nuttx-apps > repo at the same time, breaks build/runtime/api for single or many > boards/architectures/applications, breaks self-compatibility, breaks > build/runtime compatibility with existing release code (packages) both > for nuttx and nuttx-apps, etc. +1: This is a good general rule to avoid "break by design". We do not want to change critical stuff that affects different areas in a breaking way. Sure there will be exceptions where breaking stuff may be unavoidable, but it must be well marked, noted, discussed, agreed, and tested before merge. In most cases changes can be made with alternative / complementary solutions that provide compatibility or choice. New features are not breaking changes, and should not break existing stuff. > 11. We respect long term maintenance and self-compatibility is our > ultimate goal. Alternative solutions and non-invasive approaches are > preferred that offers user a choice and compatibility. Breaking > changes are avoided, and planned towards next major release. +1: As above, breaking changes are not welcome and avoided, but somet
Re: [Discuss] SBOM provided with our releases
If we a gree to provide SBOM for our releases: a source SBOM (json file) file will be provided together with the download link and will provide insight on our fill source code and license a build SBOM (json file) will be generated after a build containing only the code that was compiled on that device @Sebastien Lorquet I understand your neutral position since you don't use SBOM but if we prepare for 2026 I think that we should support SBOM to help our users Comply with the EU and international requirements. Best regards Alin On Wed, 12 Feb 2025, 11:35 Sebastien Lorquet, wrote: > Hello > > I have an absolutely neutral position on this issue. > > We dont use sboms. > > but maybe in some future we might be required to provide it. However I > dont have any clue of that happening in the near or mid future. > > What does it look like? It's just a static file somewhere, right? > > Sebastien > > On 11/02/2025 10:53, Alin Jerpelea wrote: > > Hi all, > > > > I have been working on a SBOM implementation for our project and I think > > that we are getting ready top provide both source and build SBOMS like > > Zephyt. > > What is your opinion about SBOM? > > Would an SBOM help you and your company? > > > > Best regards > > Alin > > >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
On Wed, Feb 12, 2025 at 11:37 AM Tomek CEDRO wrote: > 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. +1: New authors sometimes provide single PR with different functional changes, that should split into different PRs, this should keep things clean. Sometimes big PR is required to update single area (i.e. chip drivers) then with good argumentation this should be acceptable. > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. -1: Strong -1 here because it is safer not to merge invalid code than to deal with breaks and complains after "lazy" merge. Quality requires time. It should not be a big problem to ask for discussion on mailing list, or request additional reviews on github. Otherwise we could just merge stalled PRs and nothing will work anymore :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [VOTE] NuttX Contributing Guidelines update 202502.
> 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. 0: Does this apply to the documentation as well (discussed in a different thread for LTS)? I prefer to put the docs in one PR instead of creating the second one. We have a documentation in a single repository (compared to other projects like RTEMS for example), so let's take the advantage of it. Otherwise we can split the code and documentation into two repositories. But that's harder to maintain. Also another example is the implementing a new peripheral for some MCU. This implementation SHOULD come with another commit that adds the support for it to BSP, otherwise the CI jobs for the peripheral are useless, the new code is not build at all. > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. -1 in case we don't require 4 reviewers for every PR, but only for major and potentially breaking ones, otherwise +1. Michal On 2/12/25 11:37, Tomek CEDRO wrote: > Lets add these two points to vote that came out of the discussion and > see the reaction. > > This vote is to see what subjects we do agree already and what needs > update / clarification :-) Where are all +1 we can implement already, > where is at least one -1 that needs fix, where is 0 we may clarify > some information with the feedback provided :-) > > > 18. Pull Requests should be as small as possible and focused on only > one functional change. Different functional changes should be provided > in separate Pull Requests. Remember that breaking changes are not > welcome. Pull Requests must not break overall build, runtime, and > compatibility, especially for other components. When changes must be > bundled together in order to maintain functionality and > self-compatibility, exception can be made, and this must be clearly > stated there is no other way. > > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. > >
Re: NuttX Code Quality Improvement 2025Q1
I am redirecting questions from Takashi to this thread :-) On Wed, Feb 12, 2025 at 6:45 AM Takashi Yamamoto wrote: > On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote: > > 7. Each git commit message must consist of topic, description, and > > signature, which are mandatory, or change is auto-rejected until fixed > > / updated. Topic consists of functional prefix, ":" mark, and short > > self-explanatory context. Description is separated from topic with a > > single blank line. Example already presented in Contributing > > Guidelines. > > what's "signature" in this context? This is simple "sign-off" perfomed by `git commit -s` so we can see the git commit author name and email address, those information should be valid, we should add that info right? I don't think we require some sort of agreeements from committers, nor signing with cryptography like gpg/pgp right? > > 16. Single company commit, review, merge is not allowed. > > how do you attribute people to companies/organizations? Good question. At the moment one person from organization X can send commits / pr, two people from organization X can approve, and the code is merged. This was the concern raised in recent discussions. The idea is that single organization / company / university does not push their changes without cross-check, especially when code is untested, breaking, or pr / commits are not well described / discussed. Thus my idea for 4 independent reviews not 2. But there may be other ways to solve this? Our committers should have company / affiliation assigned so things are crystal clear. https://nuttx.apache.org/community-members/ There is only affiliation filled in :-P Thank you! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [Discuss] SBOM provided with our releases
Hello I have an absolutely neutral position on this issue. We dont use sboms. but maybe in some future we might be required to provide it. However I dont have any clue of that happening in the near or mid future. What does it look like? It's just a static file somewhere, right? Sebastien On 11/02/2025 10:53, Alin Jerpelea wrote: Hi all, I have been working on a SBOM implementation for our project and I think that we are getting ready top provide both source and build SBOMS like Zephyt. What is your opinion about SBOM? Would an SBOM help you and your company? Best regards Alin
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Lets add these two points to vote that came out of the discussion and see the reaction. This vote is to see what subjects we do agree already and what needs update / clarification :-) Where are all +1 we can implement already, where is at least one -1 that needs fix, where is 0 we may clarify some information with the feedback provided :-) 18. Pull Requests should be as small as possible and focused on only one functional change. Different functional changes should be provided in separate Pull Requests. Remember that breaking changes are not welcome. Pull Requests must not break overall build, runtime, and compatibility, especially for other components. When changes must be bundled together in order to maintain functionality and self-compatibility, exception can be made, and this must be clearly stated there is no other way. 19. "Lazy consensus" is a situation where PR is auto-merged into the upstream when not enough reviews are done in predefined time (i.e. there are no minimum required positive reviews within two weeks time). PR should initially be treated according the general rules (4 independent reviewers); After a week without enough reviewers, a call should be made on the mailing list, explaining why the PR can't be split into smaller PRs; After two weeks without any reviewers, we could merge if the above conditions are met and we have at least one independent reviewer. This may solve situation when we don't have enough people to review it (or we are not interested in that). It prevents people from forking the project just to be able to develop their stuff: *we* *really would not like that*. The PR's author is still responsible for fixing some bugs if found in the future. -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [VOTE] NuttX Contributing Guidelines update 202502.
On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano wrote: > Hi! > Tomek, there is an important missing point about 19 (that is part of my > proposal): > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > > upstream when not enough reviews are done in predefined time (i.e. > > there are no minimum required positive reviews within two weeks time). > > PR should initially be treated according the general rules (4 > > independent reviewers); After a week without enough reviewers, a call > > should be made on the > > mailing list, explaining why the PR can't be split into smaller PRs; > > After two weeks without any reviewers, we could merge if the above > > conditions are met and we have at least one independent reviewer. This > > may solve situation when we don't have enough people to review it (or > > we are not interested in that). It prevents people from forking the > > project just to be able to develop their stuff: *we* *really would not > > like that*. The PR's author is still responsible for fixing some > > bugs if found in the future. > > > It's missing that a PR has to be *eligible *for requiring it and this > includes some specific situations: > - It should not affect more than one chip/board; > - It applies to new features and apps that have no associated breaking > changes and backward compatibility; > - It requires at least one independent reviewer; > - It requires an extensive testing section and proper documentation. > > These are *mandatory *conditions and we can vote it without it (this was > part of my considerations about *Lazy Consensus*). I would be against > proposition 19 it if these requirements are missing. > > Can you please update proposition 19 and reconsider your vote based on the > requirements? Hey there Tiago :-) This voting is to identify general rules that we all agree on already. These points are supposed to be extract from our discussions. If I missed some key points please add them here folks! For proposed rules with doubts (0 or -1 votes) we should discuss more and update maybe even finally reject them. On weekend we will gather and sum up the current vote results. Then discussion will follow, where we may make clarifications, update doubted rules, and vote again. The goal is to have common agreement on the rules update. What we want to add and what form this is all up to us. No one wants to enforce anything or create a monster that will make our work harder, just a tool to help in review and code quality improvement :-) If I provided incomplete information on proposition 19 then I am sorry! Tiago you are the author, please send updated proposition 19 text and note the old one is cancelled :-) Thanks!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Regarding bmi270
Hi Yashvi, Please send the dump of this crash, using it you can find where the code is crashing. BR, Alan On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah wrote: > Hello, > > I am attempting to retrieve data from a BMI270 sensor on an STM32H7 board. > > However, when using the I2C scanner, a peculiar error is generated in > Minicom. > > The error is dump_assert_info : current version: nuttx 12.8.0 > > > Furthermore, when trying to configure (make menuconfig-> application > configuration-> example).there no option of bmi270 > > Could you please assist me in resolving this issue? > > Thank you. >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Hi! Tomek, there is an important missing point about 19 (that is part of my proposal): 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. It's missing that a PR has to be *eligible *for requiring it and this includes some specific situations: - It should not affect more than one chip/board; - It applies to new features and apps that have no associated breaking changes and backward compatibility; - It requires at least one independent reviewer; - It requires an extensive testing section and proper documentation. These are *mandatory *conditions and we can vote it without it (this was part of my considerations about *Lazy Consensus*). I would be against proposition 19 it if these requirements are missing. Can you please update proposition 19 and reconsider your vote based on the requirements? Em qua., 12 de fev. de 2025 às 09:32, Michal Lenc escreveu: > > 18. Pull Requests should be as small as possible and focused on only > > one functional change. Different functional changes should be provided > > in separate Pull Requests. Remember that breaking changes are not > > welcome. Pull Requests must not break overall build, runtime, and > > compatibility, especially for other components. When changes must be > > bundled together in order to maintain functionality and > > self-compatibility, exception can be made, and this must be clearly > > stated there is no other way. > > 0: Does this apply to the documentation as well (discussed in a > different thread for LTS)? I prefer to put the docs in one PR instead of > creating the second one. We have a documentation in a single repository > (compared to other projects like RTEMS for example), so let's take the > advantage of it. Otherwise we can split the code and documentation into > two repositories. But that's harder to maintain. > > Also another example is the implementing a new peripheral for some MCU. > This implementation SHOULD come with another commit that adds the > support for it to BSP, otherwise the CI jobs for the peripheral are > useless, the new code is not build at all. > > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > > upstream when not enough reviews are done in predefined time (i.e. > > there are no minimum required positive reviews within two weeks time). > > PR should initially be treated according the general rules (4 > > independent reviewers); After a week without enough reviewers, a call > > should be made on the > > mailing list, explaining why the PR can't be split into smaller PRs; > > After two weeks without any reviewers, we could merge if the above > > conditions are met and we have at least one independent reviewer. This > > may solve situation when we don't have enough people to review it (or > > we are not interested in that). It prevents people from forking the > > project just to be able to develop their stuff: *we* *really would not > > like that*. The PR's author is still responsible for fixing some > > bugs if found in the future. > > -1 in case we don't require 4 reviewers for every PR, but only for major > and potentially breaking ones, otherwise +1. > > Michal > > On 2/12/25 11:37, Tomek CEDRO wrote: > > Lets add these two points to vote that came out of the discussion and > > see the reaction. > > > > This vote is to see what subjects we do agree already and what needs > > update / clarification :-) Where are all +1 we can implement already, > > where is at least one -1 that needs fix, where is 0 we may clarify > > some information with the feedback provided :-) > > > > > > 18. Pull Requests should be as small as possible and focused on only > > one functional change. Different functional changes should be provided > > in separate Pull Requests. Remember that breaking changes are not > > welcome. Pull Requests must not break overall build, runtime, and > > compatibility, especially for other components. When changes must be > > bundled together in order to maintain functionality and > > self-compatibility, exception can be made, and this must be clearly > > stated there is no other way. > > > > > > 19. "Lazy consensus" is a situation where PR is auto-merg
Re: [Discuss] SBOM provided with our releases
On Wed, Feb 12, 2025 at 12:11 PM Alin Jerpelea wrote: > If we a gree to provide SBOM for our releases: > a source SBOM (json file) file will be provided together with the download > link and will provide insight on our fill source code and license > a build SBOM (json file) will be generated after a build containing only > the code that was compiled on that device > > @Sebastien Lorquet I understand your neutral > position since you don't use SBOM but if we prepare for 2026 I think that > we should > support SBOM to help our users Comply with the EU and international > requirements. Maybe an update of documentation would help here to show what it is, how it works, who needs it and why, what it solves? I typed 'sbom' into our documentation search field and nothing was found.. but I know this is important area for various reasons :-P -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [VOTE] NuttX Contributing Guidelines update 202502.
On Wed, Feb 12, 2025 at 6:45 AM Takashi Yamamoto wrote: > On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote: > > 7. Each git commit message must consist of topic, description, and > > signature, which are mandatory, or change is auto-rejected until fixed > > / updated. Topic consists of functional prefix, ":" mark, and short > > self-explanatory context. Description is separated from topic with a > > single blank line. Example already presented in Contributing > > Guidelines. > > what's "signature" in this context? > > > 16. Single company commit, review, merge is not allowed. > > how do you attribute people to companies/organizations? Thank you Takashi, good questions!! Lets discuss them in a separate thread dedicated to Code Quality Improvements. This vote is mainly to see what we all agree on already and what needs more discussion :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: [Discuss] LTS releases
Nathan, that's not what I mean.Look at this comment from Alin and discussion below it: https://github.com/apache/nuttx/pull/15789#issuecomment-2648017787 wt., 11 lut 2025 o 21:33 Nathan Hartman napisał(a): > There will be regular releases as well and if I am understanding correctly, > all PRs that are accepted will go to a regular release, and in addition, > those that are important bugfixes or security will be backported to the LTS > release also. So it's not that PRs would be harder to accept, just that > we'll be a bit more careful about which ones will be backported to the > stable, LTS releases. > > On Tue, Feb 11, 2025 at 12:46 PM raiden00pl wrote: > > > I personally don't care about LTS releases and it seems to me that Nuttx > > doesn't > > have the resources for it. But if there are people willing to work on > this > > this, > > I wish them good luck. What I don't like is the fact that the new PR > > requirements > > for LTS will make life as difficult as possible for contributors. > > Compensating for > > lack of resources by making it harder for contributors is the wrong > > approach. > > > > > > wt., 11 lut 2025 o 15:07 Nathan Hartman > > napisał(a): > > > > > I also think LTS point releases should focus on bugfixes and security > > only, > > > to ensure the maximum stability. > > > > > > Nathan > > > > > > On Tue, Feb 11, 2025 at 8:32 AM Sebastien Lorquet < > sebast...@lorquet.fr> > > > wrote: > > > > > > > Hello, > > > > > > > > I agree. Only bugfixes, criticity threshold to be determined, but new > > > > features seem unnecessary to me. > > > > > > > > Sebastien > > > > > > > > > > > > On 11/02/2025 12:43, Tiago Medicci Serrano wrote: > > > > > Hi, > > > > > > > > > > I would make the scope even more restricted. Considering an LTS > > should > > > be > > > > > 100% compatible with an existing defconfig, it should not add new > > > drivers > > > > > and new HW. I propose it to contain only bugfixes and security > > patches. > > > > > > > > > > Best regards, > > > > > > > > > > Em ter., 11 de fev. de 2025 às 08:27, Alin Jerpelea < > > > jerpe...@gmail.com> > > > > > escreveu: > > > > > > > > > >> I propose that for our first LTS we start with a small scope and > we > > > > >> backport only fixes, new hw and drivers > > > > >> > > > > >> For the future releases we may consider expanding the scope if the > > > > workload > > > > >> permits > > > > >> > > > > >> What do you think ? > > > > >> > > > > >> On Tue, Feb 11, 2025 at 10:55 AM Laczen JMS > > > > wrote: > > > > >> > > > > >>> Hi Alin, > > > > >>> > > > > >>> I also encourage this. I would start by defining what is expected > > > from > > > > a > > > > >>> LTS: > > > > >>> > > > > >>> A LTS release of NuttX is a release that will be maintained and > > > > >>> supported over a longer period of time (1 year). > > > > >>> LTS updates are mainly focused on bugfixes that where discovered > > and > > > > >>> corrected during the support period. > > > > >>> These bugfixes will be backported to the LTS release. > > > > >>> > > > > >>> Should new features and hardware be allowed in a LTS? If so, how > > many > > > > >>> releases should they have been in? > > > > >>> Many users will keep there own defconfig for a certain product, > > > should > > > > >>> they remain valid? If so are Kconfig changes allowed? > > > > >>> > > > > >>> Anyhow thanks for the proposal, > > > > >>> > > > > >>> Jehudi > > > > >>> > > > > >>> Op di 11 feb 2025 om 10:02 schreef Michael Jung < > > > > michael.j...@secore.ly > > > > >>> : > > > > Hello Alin, > > > > > > > > I would love to see this, as it would make maintaining our > product > > > > much > > > > easier. > > > > > > > > Thanks for the proposal. > > > > > > > > Michael > > > > > > > > On Tue, Feb 11, 2025 at 9:55 AM Alin Jerpelea < > jerpe...@gmail.com > > > > > > > >>> wrote: > > > > > Hi all, > > > > > > > > > > there have been suggestions that we should create LTS releases > > > > > > > > > > I propose that we mark every Q1 (match) release as a LTS > release > > > and > > > > > maintain it for 2 years. this would always ensure a fresh LTS > > > > >>> overlapping > > > > > the old one and allowing the users to migrate the code to the > new > > > > >>> release. > > > > > What do you think? > > > > > > > > > > Best regards > > > > > Alin > > > > > > > > > > > > > > >
Re: [Discuss] SBOM provided with our releases
On Tue, Feb 11, 2025 at 10:54 AM Alin Jerpelea wrote: > Hi all, > I have been working on a SBOM implementation for our project and I think > that we are getting ready top provide both source and build SBOMS like > Zephyt. > What is your opinion about SBOM? > Would an SBOM help you and your company? Thanks Alin for your hard and tedious work on SBOM! Yes, this is important for two main reasons: 1. It clarifies legal part regarding licensing. 2. It clarifies technical part regarding dependencies that impacts maintenance. Along providing SBOM solution it would be nice to provide bullet points on why this is important, what if provides, and how this can be used :-) Thanks again! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: Regarding bmi270
Yes Details of error dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 2025 0m dump_assert_info: Assertion failed panic: at file: :0 task: process: K5 up_dump_register: R0: 4000541c R1: R2: 0048 R3: 0001 up_dump_register: R4: R5: R6: FP: up_dump_register: R8: SB: SL: R11: up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: 0800dcbe up_dump_register: xPSR: 2100 BASEPRI: CONTROL: up_dump_register: EXC_RETURN: ffe9 dump_stackinfo: User Stack: dump_stackinfo: base: 0x38000208 dump_stackinfo: size: 2008 dump_stackinfo: sp: 0x380008b0 stack_dump: 0x38000890: 0d stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c 00 stack_dump: 0x380008d0: 24f4 38000a48 39 stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 0f stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 08009b71 38 stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 7f stack_dump: 0x38000950: 0030 380009e8 38000a48 08001e9d 00 stack_dump: 0x38000970: 08001e25 080023b1 00 stack_dump: 0x38000990: 08003ddc 0100 01 stack_dump: 0x380009b0: 380001f0 0001 08003e33 380001f0 00 stack_dump: 0x380009d0: 0001 0001 00 dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT SIGMASK D dump_task: 0 0 0 FIFO Kthread - Ready 00> dump_task: 1 0 240 RR Kthread - Running 00> On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: > Hi Yashvi, > > Please send the dump of this crash, using it you can find where the code is > crashing. > > BR, > > Alan > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah > wrote: > > > Hello, > > > > I am attempting to retrieve data from a BMI270 sensor on an STM32H7 > board. > > > > However, when using the I2C scanner, a peculiar error is generated in > > Minicom. > > > > The error is dump_assert_info : current version: nuttx 12.8.0 > > > > > > Furthermore, when trying to configure (make menuconfig-> application > > configuration-> example).there no option of bmi270 > > > > Could you please assist me in resolving this issue? > > > > Thank you. > > >
Re: Regarding bmi270
Hi Yashvi, You can enable the debug symbols to inspect where your code is crashing (the positions at LR: 0800d3b7 PC: 0800dcbe) Enable it in your menuconfig: Build Setup ---> Debug Options ---> [*] Generate Debug Symbols Then flash the new image and run: arm-none-eabi-addr2line -e nuttx 0800d3b7 arm-none-eabi-addr2line -e nuttx 0800dcbe Probably these LR and PC values will change for your new image, then modify the commands above to use the new values. BR, Alan On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah wrote: > Yes > > Details of error > > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 > 2025 0m > dump_assert_info: Assertion failed panic: at file: :0 task: > process: K5 > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > 0001 > up_dump_register: R4: R5: R6: FP: > > up_dump_register: R8: SB: SL: R11: > > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > 0800dcbe > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > up_dump_register: EXC_RETURN: > ffe9 > dump_stackinfo: User > Stack: > dump_stackinfo: base: > 0x38000208 > dump_stackinfo: size: > 2008 > dump_stackinfo: sp: > 0x380008b0 > stack_dump: 0x38000890: > 0d > stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c > 00 > stack_dump: 0x380008d0: 24f4 38000a48 > 39 > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 > 0f > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > 08009b71 38 > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 > 7f > stack_dump: 0x38000950: 0030 380009e8 38000a48 > 08001e9d 00 > stack_dump: 0x38000970: 08001e25 080023b1 > 00 > stack_dump: 0x38000990: 08003ddc 0100 > 01 > stack_dump: 0x380009b0: 380001f0 0001 08003e33 > 380001f0 00 > stack_dump: 0x380009d0: 0001 0001 > 00 > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > SIGMASK D > dump_task: 0 0 0 FIFO Kthread - Ready > 00> > dump_task: 1 0 240 RR Kthread - Running > 00> > > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: > > > Hi Yashvi, > > > > Please send the dump of this crash, using it you can find where the code > is > > crashing. > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah > > wrote: > > > > > Hello, > > > > > > I am attempting to retrieve data from a BMI270 sensor on an STM32H7 > > board. > > > > > > However, when using the I2C scanner, a peculiar error is generated in > > > Minicom. > > > > > > The error is dump_assert_info : current version: nuttx 12.8.0 > > > > > > > > > Furthermore, when trying to configure (make menuconfig-> application > > > configuration-> example).there no option of bmi270 > > > > > > Could you please assist me in resolving this issue? > > > > > > Thank you. > > > > > >
Re: [Discuss] SBOM provided with our releases
Hello, Fine, I have no opposition, and yes it could become actually useful. As Tomek noticed, we also need to document what it is so it has an impact on many docs, and also on the website. Sebastien On 12/02/2025 12:11, Alin Jerpelea wrote: If we a gree to provide SBOM for our releases: a source SBOM (json file) file will be provided together with the download link and will provide insight on our fill source code and license a build SBOM (json file) will be generated after a build containing only the code that was compiled on that device @Sebastien Lorquet I understand your neutral position since you don't use SBOM but if we prepare for 2026 I think that we should support SBOM to help our users Comply with the EU and international requirements. Best regards Alin On Wed, 12 Feb 2025, 11:35 Sebastien Lorquet, wrote: Hello I have an absolutely neutral position on this issue. We dont use sboms. but maybe in some future we might be required to provide it. However I dont have any clue of that happening in the near or mid future. What does it look like? It's just a static file somewhere, right? Sebastien On 11/02/2025 10:53, Alin Jerpelea wrote: Hi all, I have been working on a SBOM implementation for our project and I think that we are getting ready top provide both source and build SBOMS like Zephyt. What is your opinion about SBOM? Would an SBOM help you and your company? Best regards Alin
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Hi! Thanks, Tomek ;) So, rewriting 19: *19.* A PR may be *eligible* to be merged under the concept of *Lazy consensus* with the following conditions: - It affects only a single chip or board (no kernel/libs/upper-half drivers etc); - It implements a new feature (or app) that doesn't introduce any breaking changes or backward incompatibility; - It didn't get the minimum of 4 reviewers after two weeks (to be discussed); - At least one independent reviewer reviewed it; - It adheres to all other conditions. The PR's author should: - After a week (to be discussed) without any reviewers, send an e-mail to the mailing list asking for more people to review it; - Explain why the PR can't be split into smaller PRs (if applicable); - Ask for the independent reviewer to merge it after two weeks without any other reviewers; *The (required) independent reviewer* is responsible for checking if the PR matches the *Lazy Consensus* conditions and merging it. Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO escreveu: > On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano > wrote: > > Hi! > > Tomek, there is an important missing point about 19 (that is part of my > > proposal): > > > > 19. "Lazy consensus" is a situation where PR is auto-merged into the > > > upstream when not enough reviews are done in predefined time (i.e. > > > there are no minimum required positive reviews within two weeks time). > > > PR should initially be treated according the general rules (4 > > > independent reviewers); After a week without enough reviewers, a call > > > should be made on the > > > mailing list, explaining why the PR can't be split into smaller PRs; > > > After two weeks without any reviewers, we could merge if the above > > > conditions are met and we have at least one independent reviewer. This > > > may solve situation when we don't have enough people to review it (or > > > we are not interested in that). It prevents people from forking the > > > project just to be able to develop their stuff: *we* *really would not > > > like that*. The PR's author is still responsible for fixing some > > > bugs if found in the future. > > > > > > It's missing that a PR has to be *eligible *for requiring it and this > > includes some specific situations: > > - It should not affect more than one chip/board; > > - It applies to new features and apps that have no associated breaking > > changes and backward compatibility; > > - It requires at least one independent reviewer; > > - It requires an extensive testing section and proper documentation. > > > > These are *mandatory *conditions and we can vote it without it (this was > > part of my considerations about *Lazy Consensus*). I would be against > > proposition 19 it if these requirements are missing. > > > > Can you please update proposition 19 and reconsider your vote based on > the > > requirements? > > Hey there Tiago :-) > > This voting is to identify general rules that we all agree on already. > These points are supposed to be extract from our discussions. If I > missed some key points please add them here folks! For proposed rules > with doubts (0 or -1 votes) we should discuss more and update maybe > even finally reject them. > > On weekend we will gather and sum up the current vote results. Then > discussion will follow, where we may make clarifications, update > doubted rules, and vote again. The goal is to have common agreement on > the rules update. What we want to add and what form this is all up to > us. No one wants to enforce anything or create a monster that will > make our work harder, just a tool to help in review and code quality > improvement :-) > > If I provided incomplete information on proposition 19 then I am > sorry! Tiago you are the author, please send updated proposition 19 > text and note the old one is cancelled :-) > > Thanks!! :-) > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: Best way to go about generic driver
I have created an initial RN2XX3 driver here: https://github.com/apache/nuttx/pull/15828 The design was based on some suggestions received on the mailing list earlier in the year. I haven't added quite all of the `ioctl` commands I would like yet, and I want to add some Kconfig options, but I am opening the draft PR in case I can get any pointers from the NuttX community before I get much further along. The implementation now as it stands works without any issues, I am able to transmit and receive from NuttX using another transceiver connected to my computer via USB. I even took my transmitter for a walk and got some successful long range test results! Any feedback is appreciated before I add the finishing touches and unmark as draft. Thanks, -- Matteo Golin signature.asc Description: PGP signature
Re: Regarding bmi270
Hi Yashvi, Please describe the issue you are facing. BTW, did the i2c scan find your BMI270? BR, Alan On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah wrote: > But > > I’m having a little trouble finding the BMI270 option in the application > configuration examples. > > Thank you! > > On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah > wrote: > > > > > > > Hello, > > > > By applying this, I was able to successfully execute the I2C scanner. > > > > Thank you! > > > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: > > > >> Hi Yashvi, > >> > >> You can enable the debug symbols to inspect where your code is crashing > >> (the positions at LR: 0800d3b7 PC: 0800dcbe) > >> > >> Enable it in your menuconfig: > >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > >> > >> Then flash the new image and run: > >> > >> arm-none-eabi-addr2line -e nuttx 0800d3b7 > >> arm-none-eabi-addr2line -e nuttx 0800dcbe > >> > >> Probably these LR and PC values will change for your new image, then > >> modify > >> the commands above to use the new values. > >> > >> BR, > >> > >> Alan > >> > >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah > >> wrote: > >> > >> > Yes > >> > > >> > Details of error > >> > > >> > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb > 12 > >> > 2025 0m > >> > dump_assert_info: Assertion failed panic: at file: :0 task: > >> > process: K5 > >> > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > >> > 0001 > >> > up_dump_register: R4: R5: R6: FP: > >> > > >> > up_dump_register: R8: SB: SL: R11: > >> > > >> > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > >> > 0800dcbe > >> > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > >> > > >> > up_dump_register: EXC_RETURN: > >> > ffe9 > >> > dump_stackinfo: User > >> > Stack: > >> > dump_stackinfo: base: > >> > 0x38000208 > >> > dump_stackinfo: size: > >> > 2008 > >> > dump_stackinfo: sp: > >> > 0x380008b0 > >> > stack_dump: 0x38000890: > >> > 0d > >> > stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c > >> > 00 > >> > stack_dump: 0x380008d0: 24f4 38000a48 > >> > 39 > >> > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 > >> > 0f > >> > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > >> > 08009b71 38 > >> > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 > >> > 7f > >> > stack_dump: 0x38000950: 0030 380009e8 38000a48 > >> > 08001e9d 00 > >> > stack_dump: 0x38000970: 08001e25 080023b1 > >> > 00 > >> > stack_dump: 0x38000990: 08003ddc 0100 > >> > 01 > >> > stack_dump: 0x380009b0: 380001f0 0001 08003e33 > >> > 380001f0 00 > >> > stack_dump: 0x380009d0: 0001 0001 > >> > 00 > >> > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > >> > SIGMASK D > >> > dump_task: 0 0 0 FIFO Kthread - Ready > >> > 00> > >> > dump_task: 1 0 240 RR Kthread - Running > >> > 00> > >> > > >> > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis > wrote: > >> > > >> > > Hi Yashvi, > >> > > > >> > > Please send the dump of this crash, using it you can find where the > >> code > >> > is > >> > > crashing. > >> > > > >> > > BR, > >> > > > >> > > Alan > >> > > > >> > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < > yashvee...@gmail.com > >> > > >> > > wrote: > >> > > > >> > > > Hello, > >> > > > > >> > > > I am attempting to retrieve data from a BMI270 sensor on an > STM32H7 > >> > > board. > >> > > > > >> > > > However, when using the I2C scanner, a peculiar error is generated > >> in > >> > > > Minicom. > >> > > > > >> > > > The error is dump_assert_info : current version: nuttx 12.8.0 > >> > > > > >> > > > > >> > > > Furthermore, when trying to configure (make menuconfig-> > application > >> > > > configuration-> example).there no option of bmi270 > >> > > > > >> > > > Could you please assist me in resolving this issue? > >> > > > > >> > > > Thank you. > >> > > > > >> > > > >> > > >> > > >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Hi, Again, Sebastien, read it *carefully*. It seems you are not willing to do it. It doesn't bypass anything: - either the submitter still cares and will yell at people to get it > approved * My proposal says explicitly about this:* The PR's author should: > - After a week (to be discussed) without any reviewers, send an > e-mail to the mailing list asking for more people to review it; *Continuing:* I dont want to see unsupervised auto commits. > The conditions listed in this point (no breakage, execution of tests, > etc) HAVE TO be verified. Neither do I! That's why there is the following rule: *The (required) independent reviewer* is responsible for checking > if the PR matches the *Lazy Consensus* conditions and merging it > *THE INDEPENDENT REVIEWER *(not the PR's author) is responsible for checking and merging it. It requires *AT LEAST* one independent reviewer. So, if we were not able to have 4 reviewers *and* already asked for help. Then we can try to check if it's *eligible*. Em qua., 12 de fev. de 2025 às 15:10, Alan C. Assis escreveu: > The goal is not to automatically merge PR, but only to avoid that some PRs > that don't reach the maximum number of reviews be allowed to be merged. > > Typically, those who are most eager to impose new rules are not the same as > those who are subject to them! > > BR, > > Alan > > > > > > > On Wed, Feb 12, 2025 at 2:55 PM Sebastien Lorquet > wrote: > > > Again, I will vote against this. Not that it matters if a majority wants > > to approve it. > > > > This is a bypass of all other rules we're trying to enforce. > > > > If such situation arise, there are two cases: > > > > - either the submitter still cares and will yell at people to get it > > approved > > > > - either it will be dropped entirely. > > > > I dont want to see unsupervised auto commits. > > > > The conditions listed in this point (no breakage, execution of tests, > > etc) HAVE TO be verified. > > > > Sebastien > > > > > > On 12/02/2025 17:14, Tiago Medicci Serrano wrote: > > > Hi! > > > > > > Thanks, Tomek ;) > > > > > > So, rewriting 19: > > > > > > *19.* A PR may be *eligible* to be merged under the concept of *Lazy > > > consensus* with the following conditions: > > >- It affects only a single chip or board (no > > > kernel/libs/upper-half drivers etc); > > >- It implements a new feature (or app) that doesn't > introduce > > any > > > breaking changes or backward incompatibility; > > >- It didn't get the minimum of 4 reviewers after two weeks > > (to be > > > discussed); > > > - At least one independent reviewer reviewed it; > > >- It adheres to all other conditions. > > > The PR's author should: > > >- After a week (to be discussed) without any reviewers, send > > an > > > e-mail to the mailing list asking for more people to review it; > > >- Explain why the PR can't be split into smaller PRs (if > > > applicable); > > >- Ask for the independent reviewer to merge it after two > weeks > > > without any other reviewers; > > > *The (required) independent reviewer* is responsible for > > checking > > > if the PR matches the *Lazy Consensus* conditions and merging it. > > > > > > Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO > > > escreveu: > > > > > >> On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano > > >> wrote: > > >>> Hi! > > >>> Tomek, there is an important missing point about 19 (that is part of > my > > >>> proposal): > > >>> > > >>> 19. "Lazy consensus" is a situation where PR is auto-merged into the > > upstream when not enough reviews are done in predefined time (i.e. > > there are no minimum required positive reviews within two weeks > time). > > PR should initially be treated according the general rules (4 > > independent reviewers); After a week without enough reviewers, a > call > > should be made on the > > mailing list, explaining why the PR can't be split into smaller > PRs; > > After two weeks without any reviewers, we could merge if the above > > conditions are met and we have at least one independent reviewer. > This > > may solve situation when we don't have enough people to review it > (or > > we are not interested in that). It prevents people from forking the > > project just to be able to develop their stuff: *we* *really would > not > > like that*. The PR's author is still responsible for fixing some > > bugs if found in the future. > > >>> > > >>> It's missing that a PR has to be *eligible *for requiring it and this > > >>> includes some specific situations: > > >>> - It should not affect more than one chip/board; > > >>> - It applies to new features and apps that have no associated > breaking > > >>> changes and backward compatibility; > > >>> - It requires at least one independent reviewer; > > >>> - It requires an extensive testing sec
Re: Regarding bmi270
Yes, I successfully completed the I2C scanner. After achieving success with I2C, I need to retrieve data from the BMI270. For that, I have done all the necessary configurations, and everything seems perfect. However, when I try to enable the BMI270 in the application configuration -> "Examples," there is no option for the BMI270 sensor. On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis wrote: > Hi Yashvi, > > Please describe the issue you are facing. BTW, did the i2c scan find your > BMI270? > > BR, > > Alan > > On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah > wrote: > > > But > > > > I’m having a little trouble finding the BMI270 option in the application > > configuration examples. > > > > Thank you! > > > > On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah > > wrote: > > > > > > > > > > > Hello, > > > > > > By applying this, I was able to successfully execute the I2C scanner. > > > > > > Thank you! > > > > > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: > > > > > >> Hi Yashvi, > > >> > > >> You can enable the debug symbols to inspect where your code is > crashing > > >> (the positions at LR: 0800d3b7 PC: 0800dcbe) > > >> > > >> Enable it in your menuconfig: > > >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > >> > > >> Then flash the new image and run: > > >> > > >> arm-none-eabi-addr2line -e nuttx 0800d3b7 > > >> arm-none-eabi-addr2line -e nuttx 0800dcbe > > >> > > >> Probably these LR and PC values will change for your new image, then > > >> modify > > >> the commands above to use the new values. > > >> > > >> BR, > > >> > > >> Alan > > >> > > >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > yashvee...@gmail.com> > > >> wrote: > > >> > > >> > Yes > > >> > > > >> > Details of error > > >> > > > >> > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > Feb > > 12 > > >> > 2025 0m > > >> > dump_assert_info: Assertion failed panic: at file: :0 task: > > >> > process: K5 > > >> > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > >> > 0001 > > >> > up_dump_register: R4: R5: R6: FP: > > >> > > > >> > up_dump_register: R8: SB: SL: R11: > > >> > > > >> > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > >> > 0800dcbe > > >> > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > >> > > > >> > up_dump_register: EXC_RETURN: > > >> > ffe9 > > >> > dump_stackinfo: User > > >> > Stack: > > >> > dump_stackinfo: base: > > >> > 0x38000208 > > >> > dump_stackinfo: size: > > >> > 2008 > > >> > dump_stackinfo: sp: > > >> > 0x380008b0 > > >> > stack_dump: 0x38000890: > > >> > 0d > > >> > stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c > > >> > 00 > > >> > stack_dump: 0x380008d0: 24f4 38000a48 > > >> > 39 > > >> > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 > > >> > 0f > > >> > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > >> > 08009b71 38 > > >> > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 > > >> > 7f > > >> > stack_dump: 0x38000950: 0030 380009e8 38000a48 > > >> > 08001e9d 00 > > >> > stack_dump: 0x38000970: 08001e25 080023b1 > > >> > 00 > > >> > stack_dump: 0x38000990: 08003ddc 0100 > > >> > 01 > > >> > stack_dump: 0x380009b0: 380001f0 0001 08003e33 > > >> > 380001f0 00 > > >> > stack_dump: 0x380009d0: 0001 0001 > > >> > 00 > > >> > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > > >> > SIGMASK D > > >> > dump_task: 0 0 0 FIFO Kthread - Ready > > >> > 00> > > >> > dump_task: 1 0 240 RR Kthread - Running > > >> > 00> > > >> > > > >> > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis > > wrote: > > >> > > > >> > > Hi Yashvi, > > >> > > > > >> > > Please send the dump of this crash, using it you can find where > the > > >> code > > >> > is > > >> > > crashing. > > >> > > > > >> > > BR, > > >> > > > > >> > > Alan > > >> > > > > >> > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < > > yashvee...@gmail.com > > >> > > > >> > > wrote: > > >> > > > > >> > > > Hello, > > >> > > > > > >> > > > I am attempting to retrieve data from a BMI270 sensor on an > > STM32H7 > > >> > > board. > > >> > > > > > >> > > > However, when using the I2C scanner, a peculiar error is > generated > > >> in > > >> > > > Minicom. > > >> > > > > > >> > > > The error is dump_assert_info : current version: nuttx 12.8.0 > > >> > > > > > >> > > > > > >> > > > Furthermore, when trying to configure (make menuconfig-> > > application > > >> > > > configuration-> example).there no option of bmi270 > > >> > > > > > >>
Re: Regarding bmi270
Hello I enabled the sensortest in sensor drive <- testing<- application configuration.. But in ls/dev Uorb is not available+ imu0 is visible On Thu, Feb 13, 2025, 1:00 AM Alan C. Assis wrote: > Hi Tim, > > It came from PX4 and how it is used for our sensors. > > BR, > > Alan > > On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty > wrote: > > > Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too > > and I missed it? > > > > Just curious :-) > > > > On 12/02/2025 18:51, Alan C. Assis wrote: > > > Hi Yashvi, > > > > > > BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) > > > > > > Just verify if the sensor was created correctly at /dev/uorb/ > > > > > > BR, > > > > > > Alan > > > > > > On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah > > > wrote: > > > > > >> Yes, I successfully completed the I2C scanner. > > >> > > >> After achieving success with I2C, I need to retrieve data from the > > BMI270. > > >> For that, I have done all the necessary configurations, and everything > > >> seems perfect. However, when I try to enable the BMI270 in the > > application > > >> configuration -> "Examples," there is no option for the BMI270 sensor. > > >> > > >> On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis > wrote: > > >> > > >>> Hi Yashvi, > > >>> > > >>> Please describe the issue you are facing. BTW, did the i2c scan find > > your > > >>> BMI270? > > >>> > > >>> BR, > > >>> > > >>> Alan > > >>> > > >>> On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah < > yashvee...@gmail.com> > > >>> wrote: > > >>> > > But > > > > I’m having a little trouble finding the BMI270 option in the > > >> application > > configuration examples. > > > > Thank you! > > > > On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah < > yashvee...@gmail.com> > > wrote: > > > > > > > > Hello, > > > > > > By applying this, I was able to successfully execute the I2C > scanner. > > > > > > Thank you! > > > > > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis > > >> wrote: > > >> Hi Yashvi, > > >> > > >> You can enable the debug symbols to inspect where your code is > > >>> crashing > > >> (the positions at LR: 0800d3b7 PC: 0800dcbe) > > >> > > >> Enable it in your menuconfig: > > >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > >> > > >> Then flash the new image and run: > > >> > > >> arm-none-eabi-addr2line -e nuttx 0800d3b7 > > >> arm-none-eabi-addr2line -e nuttx 0800dcbe > > >> > > >> Probably these LR and PC values will change for your new image, > then > > >> modify > > >> the commands above to use the new values. > > >> > > >> BR, > > >> > > >> Alan > > >> > > >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > > >>> yashvee...@gmail.com> > > >> wrote: > > >> > > >>> Yes > > >>> > > >>> Details of error > > >>> > > >>> dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > > >>> Feb > > 12 > > >>> 2025 0m > > >>> dump_assert_info: Assertion failed panic: at file: :0 task: > > >> > > >>> process: K5 > > >>> up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > >>> 0001 > > >>> up_dump_register: R4: R5: R6: FP: > > >>> > > >>> up_dump_register: R8: SB: SL: R11: > > >>> > > >>> up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > >>> 0800dcbe > > >>> up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > >>> > > >>> up_dump_register: EXC_RETURN: > > >>> ffe9 > > >>> dump_stackinfo: User > > >>> Stack: > > >>> dump_stackinfo: base: > > >>> 0x38000208 > > >>> dump_stackinfo: size: > > >>> 2008 > > >>> dump_stackinfo: sp: > > >>> 0x380008b0 > > >>> stack_dump: 0x38000890: > > >> > > >>> 0d > > >>> stack_dump: 0x380008b0: 38000a48 0001 38000a48 > > >> 24001e3c > > >>> 00 > > >>> stack_dump: 0x380008d0: 24f4 38000a48 > > >> > > >>> 39 > > >>> stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 > > >> 24f4 > > >>> 0f > > >>> stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > >> > > >>> 08009b71 38 > > >>> stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 > > >> 0001 > > >>> 7f > > >>> stack_dump: 0x38000950: 0030 380009e8 38000a48 > > >> > > >>> 08001e9d 00 > > >>> stack_dump: 0x38000970: 08001e25 080023b1 > > >> > > >>> 00 > > >>> stack_dump: 0x38000990: 08003ddc 0100 > > >> > > >>> 01 > > >>> stack_dump: 0
Re: Regarding bmi270
Ah - so something you choose to use or not? But still we'll have "traditional" drivers for new sensors as they're added? On 12/02/2025 19:29, Alan C. Assis wrote: Hi Tim, It came from PX4 and how it is used for our sensors. BR, Alan On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty wrote: Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too and I missed it? Just curious :-) On 12/02/2025 18:51, Alan C. Assis wrote: Hi Yashvi, BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) Just verify if the sensor was created correctly at /dev/uorb/ BR, Alan On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah wrote: Yes, I successfully completed the I2C scanner. After achieving success with I2C, I need to retrieve data from the BMI270. For that, I have done all the necessary configurations, and everything seems perfect. However, when I try to enable the BMI270 in the application configuration -> "Examples," there is no option for the BMI270 sensor. On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis wrote: Hi Yashvi, Please describe the issue you are facing. BTW, did the i2c scan find your BMI270? BR, Alan On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah wrote: But I’m having a little trouble finding the BMI270 option in the application configuration examples. Thank you! On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah wrote: Hello, By applying this, I was able to successfully execute the I2C scanner. Thank you! On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: Hi Yashvi, You can enable the debug symbols to inspect where your code is crashing (the positions at LR: 0800d3b7 PC: 0800dcbe) Enable it in your menuconfig: Build Setup ---> Debug Options ---> [*] Generate Debug Symbols Then flash the new image and run: arm-none-eabi-addr2line -e nuttx 0800d3b7 arm-none-eabi-addr2line -e nuttx 0800dcbe Probably these LR and PC values will change for your new image, then modify the commands above to use the new values. BR, Alan On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < yashvee...@gmail.com> wrote: Yes Details of error dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 2025 0m dump_assert_info: Assertion failed panic: at file: :0 task: process: K5 up_dump_register: R0: 4000541c R1: R2: 0048 R3: 0001 up_dump_register: R4: R5: R6: FP: up_dump_register: R8: SB: SL: R11: up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: 0800dcbe up_dump_register: xPSR: 2100 BASEPRI: CONTROL: up_dump_register: EXC_RETURN: ffe9 dump_stackinfo: User Stack: dump_stackinfo: base: 0x38000208 dump_stackinfo: size: 2008 dump_stackinfo: sp: 0x380008b0 stack_dump: 0x38000890: 0d stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c 00 stack_dump: 0x380008d0: 24f4 38000a48 39 stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 0f stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 08009b71 38 stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 7f stack_dump: 0x38000950: 0030 380009e8 38000a48 08001e9d 00 stack_dump: 0x38000970: 08001e25 080023b1 00 stack_dump: 0x38000990: 08003ddc 0100 01 stack_dump: 0x380009b0: 380001f0 0001 08003e33 380001f0 00 stack_dump: 0x380009d0: 0001 0001 00 dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT SIGMASK D dump_task: 0 0 0 FIFO Kthread - Ready 00> dump_task: 1 0 240 RR Kthread - Running 00> On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: Hi Yashvi, Please send the dump of this crash, using it you can find where the code is crashing. BR, Alan On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < yashvee...@gmail.com wrote: Hello, I am attempting to retrieve data from a BMI270 sensor on an STM32H7 board. However, when using the I2C scanner, a peculiar error is generated in Minicom. The error is dump_assert_info : current version: nuttx 12.8.0 Furthermore, when trying to configure (make menuconfig-> application configuration-> example).there no option of bmi270 Could you please assist me in resolving this issue? Thank you.
Re: Regarding bmi270
I am not able to understand can you describe it briefly? Thank you! On Thu, Feb 13, 2025, 1:35 AM Tim Hardisty wrote: > Ah - so something you choose to use or not? But still we'll have > "traditional" drivers for new sensors as they're added? > > On 12/02/2025 19:29, Alan C. Assis wrote: > > Hi Tim, > > > > It came from PX4 and how it is used for our sensors. > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty > > wrote: > > > >> Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too > >> and I missed it? > >> > >> Just curious :-) > >> > >> On 12/02/2025 18:51, Alan C. Assis wrote: > >>> Hi Yashvi, > >>> > >>> BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) > >>> > >>> Just verify if the sensor was created correctly at /dev/uorb/ > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah > >>> wrote: > >>> > Yes, I successfully completed the I2C scanner. > > After achieving success with I2C, I need to retrieve data from the > >> BMI270. > For that, I have done all the necessary configurations, and everything > seems perfect. However, when I try to enable the BMI270 in the > >> application > configuration -> "Examples," there is no option for the BMI270 sensor. > > On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis > wrote: > > > Hi Yashvi, > > > > Please describe the issue you are facing. BTW, did the i2c scan find > >> your > > BMI270? > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah < > yashvee...@gmail.com> > > wrote: > > > >> But > >> > >> I’m having a little trouble finding the BMI270 option in the > application > >> configuration examples. > >> > >> Thank you! > >> > >> On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah < > yashvee...@gmail.com> > >> wrote: > >> > >>> Hello, > >>> > >>> By applying this, I was able to successfully execute the I2C > scanner. > >>> > >>> Thank you! > >>> > >>> On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis > wrote: > Hi Yashvi, > > You can enable the debug symbols to inspect where your code is > > crashing > (the positions at LR: 0800d3b7 PC: 0800dcbe) > > Enable it in your menuconfig: > Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > Then flash the new image and run: > > arm-none-eabi-addr2line -e nuttx 0800d3b7 > arm-none-eabi-addr2line -e nuttx 0800dcbe > > Probably these LR and PC values will change for your new image, > then > modify > the commands above to use the new values. > > BR, > > Alan > > On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > > yashvee...@gmail.com> > wrote: > > > Yes > > > > Details of error > > > > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > > Feb > >> 12 > > 2025 0m > > dump_assert_info: Assertion failed panic: at file: :0 task: > > > process: K5 > > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > 0001 > > up_dump_register: R4: R5: R6: FP: > > > > up_dump_register: R8: SB: SL: R11: > > > > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > 0800dcbe > > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > > > up_dump_register: EXC_RETURN: > > ffe9 > > dump_stackinfo: User > > Stack: > > dump_stackinfo: base: > > 0x38000208 > > dump_stackinfo: size: > > 2008 > > dump_stackinfo: sp: > > 0x380008b0 > > stack_dump: 0x38000890: > > > 0d > > stack_dump: 0x380008b0: 38000a48 0001 38000a48 > 24001e3c > > 00 > > stack_dump: 0x380008d0: 24f4 38000a48 > > > 39 > > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 > 24f4 > > 0f > > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > > 08009b71 38 > > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 > 0001 > > 7f > > stack_dump: 0x38000950: 0030 380009e8 38000a48 > > > 08001e9d 00 > > stack_dump: 0x38000970: 08001e25 080023b1 > > > 00 > > stack_dump: 0
Re: Regarding bmi270
Hi Tim, It came from PX4 and how it is used for our sensors. BR, Alan On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty wrote: > Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too > and I missed it? > > Just curious :-) > > On 12/02/2025 18:51, Alan C. Assis wrote: > > Hi Yashvi, > > > > BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) > > > > Just verify if the sensor was created correctly at /dev/uorb/ > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah > > wrote: > > > >> Yes, I successfully completed the I2C scanner. > >> > >> After achieving success with I2C, I need to retrieve data from the > BMI270. > >> For that, I have done all the necessary configurations, and everything > >> seems perfect. However, when I try to enable the BMI270 in the > application > >> configuration -> "Examples," there is no option for the BMI270 sensor. > >> > >> On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis wrote: > >> > >>> Hi Yashvi, > >>> > >>> Please describe the issue you are facing. BTW, did the i2c scan find > your > >>> BMI270? > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah > >>> wrote: > >>> > But > > I’m having a little trouble finding the BMI270 option in the > >> application > configuration examples. > > Thank you! > > On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah > wrote: > > > > > Hello, > > > > By applying this, I was able to successfully execute the I2C scanner. > > > > Thank you! > > > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis > >> wrote: > >> Hi Yashvi, > >> > >> You can enable the debug symbols to inspect where your code is > >>> crashing > >> (the positions at LR: 0800d3b7 PC: 0800dcbe) > >> > >> Enable it in your menuconfig: > >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > >> > >> Then flash the new image and run: > >> > >> arm-none-eabi-addr2line -e nuttx 0800d3b7 > >> arm-none-eabi-addr2line -e nuttx 0800dcbe > >> > >> Probably these LR and PC values will change for your new image, then > >> modify > >> the commands above to use the new values. > >> > >> BR, > >> > >> Alan > >> > >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > >>> yashvee...@gmail.com> > >> wrote: > >> > >>> Yes > >>> > >>> Details of error > >>> > >>> dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > >>> Feb > 12 > >>> 2025 0m > >>> dump_assert_info: Assertion failed panic: at file: :0 task: > >> > >>> process: K5 > >>> up_dump_register: R0: 4000541c R1: R2: 0048 R3: > >>> 0001 > >>> up_dump_register: R4: R5: R6: FP: > >>> > >>> up_dump_register: R8: SB: SL: R11: > >>> > >>> up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > >>> 0800dcbe > >>> up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > >>> > >>> up_dump_register: EXC_RETURN: > >>> ffe9 > >>> dump_stackinfo: User > >>> Stack: > >>> dump_stackinfo: base: > >>> 0x38000208 > >>> dump_stackinfo: size: > >>> 2008 > >>> dump_stackinfo: sp: > >>> 0x380008b0 > >>> stack_dump: 0x38000890: > >> > >>> 0d > >>> stack_dump: 0x380008b0: 38000a48 0001 38000a48 > >> 24001e3c > >>> 00 > >>> stack_dump: 0x380008d0: 24f4 38000a48 > >> > >>> 39 > >>> stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 > >> 24f4 > >>> 0f > >>> stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > >> > >>> 08009b71 38 > >>> stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 > >> 0001 > >>> 7f > >>> stack_dump: 0x38000950: 0030 380009e8 38000a48 > >> > >>> 08001e9d 00 > >>> stack_dump: 0x38000970: 08001e25 080023b1 > >> > >>> 00 > >>> stack_dump: 0x38000990: 08003ddc 0100 > >> > >>> 01 > >>> stack_dump: 0x380009b0: 380001f0 0001 08003e33 > >> > >>> 380001f0 00 > >>> stack_dump: 0x380009d0: 0001 0001 > >> > >>> 00 > >>> dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > >>> SIGMASK D > >>> dump_task: 0 0 0 FIFO Kthread - Ready > >>> 00> > >>> dump_task: 1 0 240 RR Kthread - Running > >>> 00> > >>> > >>> On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis > wrote: > Hi Yashvi, > >
Re: Regarding bmi270
Yes, we still have char driver sensors and uorb sensors On Wed, Feb 12, 2025 at 5:05 PM Tim Hardisty wrote: > Ah - so something you choose to use or not? But still we'll have > "traditional" drivers for new sensors as they're added? > > On 12/02/2025 19:29, Alan C. Assis wrote: > > Hi Tim, > > > > It came from PX4 and how it is used for our sensors. > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 4:21 PM Tim Hardisty > > wrote: > > > >> Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too > >> and I missed it? > >> > >> Just curious :-) > >> > >> On 12/02/2025 18:51, Alan C. Assis wrote: > >>> Hi Yashvi, > >>> > >>> BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) > >>> > >>> Just verify if the sensor was created correctly at /dev/uorb/ > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah > >>> wrote: > >>> > Yes, I successfully completed the I2C scanner. > > After achieving success with I2C, I need to retrieve data from the > >> BMI270. > For that, I have done all the necessary configurations, and everything > seems perfect. However, when I try to enable the BMI270 in the > >> application > configuration -> "Examples," there is no option for the BMI270 sensor. > > On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis > wrote: > > > Hi Yashvi, > > > > Please describe the issue you are facing. BTW, did the i2c scan find > >> your > > BMI270? > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah < > yashvee...@gmail.com> > > wrote: > > > >> But > >> > >> I’m having a little trouble finding the BMI270 option in the > application > >> configuration examples. > >> > >> Thank you! > >> > >> On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah < > yashvee...@gmail.com> > >> wrote: > >> > >>> Hello, > >>> > >>> By applying this, I was able to successfully execute the I2C > scanner. > >>> > >>> Thank you! > >>> > >>> On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis > wrote: > Hi Yashvi, > > You can enable the debug symbols to inspect where your code is > > crashing > (the positions at LR: 0800d3b7 PC: 0800dcbe) > > Enable it in your menuconfig: > Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > Then flash the new image and run: > > arm-none-eabi-addr2line -e nuttx 0800d3b7 > arm-none-eabi-addr2line -e nuttx 0800dcbe > > Probably these LR and PC values will change for your new image, > then > modify > the commands above to use the new values. > > BR, > > Alan > > On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > > yashvee...@gmail.com> > wrote: > > > Yes > > > > Details of error > > > > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > > Feb > >> 12 > > 2025 0m > > dump_assert_info: Assertion failed panic: at file: :0 task: > > > process: K5 > > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > 0001 > > up_dump_register: R4: R5: R6: FP: > > > > up_dump_register: R8: SB: SL: R11: > > > > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > 0800dcbe > > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > > > up_dump_register: EXC_RETURN: > > ffe9 > > dump_stackinfo: User > > Stack: > > dump_stackinfo: base: > > 0x38000208 > > dump_stackinfo: size: > > 2008 > > dump_stackinfo: sp: > > 0x380008b0 > > stack_dump: 0x38000890: > > > 0d > > stack_dump: 0x380008b0: 38000a48 0001 38000a48 > 24001e3c > > 00 > > stack_dump: 0x380008d0: 24f4 38000a48 > > > 39 > > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 > 24f4 > > 0f > > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > > 08009b71 38 > > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 > 0001 > > 7f > > stack_dump: 0x38000950: 0030 380009e8 38000a48 > > > 08001e9d 00 > > stack_dump: 0x38000970: 08001e25 080023b1 > > > 00 > > stack_dump: 0x38000990:
Re: Regarding bmi270
Hello, By applying this, I was able to successfully execute the I2C scanner. Thank you! On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: > Hi Yashvi, > > You can enable the debug symbols to inspect where your code is crashing > (the positions at LR: 0800d3b7 PC: 0800dcbe) > > Enable it in your menuconfig: > Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > Then flash the new image and run: > > arm-none-eabi-addr2line -e nuttx 0800d3b7 > arm-none-eabi-addr2line -e nuttx 0800dcbe > > Probably these LR and PC values will change for your new image, then modify > the commands above to use the new values. > > BR, > > Alan > > On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah > wrote: > > > Yes > > > > Details of error > > > > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 > > 2025 0m > > dump_assert_info: Assertion failed panic: at file: :0 task: > > process: K5 > > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > 0001 > > up_dump_register: R4: R5: R6: FP: > > > > up_dump_register: R8: SB: SL: R11: > > > > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > 0800dcbe > > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > > > up_dump_register: EXC_RETURN: > > ffe9 > > dump_stackinfo: User > > Stack: > > dump_stackinfo: base: > > 0x38000208 > > dump_stackinfo: size: > > 2008 > > dump_stackinfo: sp: > > 0x380008b0 > > stack_dump: 0x38000890: > > 0d > > stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c > > 00 > > stack_dump: 0x380008d0: 24f4 38000a48 > > 39 > > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 > > 0f > > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > 08009b71 38 > > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 > > 7f > > stack_dump: 0x38000950: 0030 380009e8 38000a48 > > 08001e9d 00 > > stack_dump: 0x38000970: 08001e25 080023b1 > > 00 > > stack_dump: 0x38000990: 08003ddc 0100 > > 01 > > stack_dump: 0x380009b0: 380001f0 0001 08003e33 > > 380001f0 00 > > stack_dump: 0x380009d0: 0001 0001 > > 00 > > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > > SIGMASK D > > dump_task: 0 0 0 FIFO Kthread - Ready > > 00> > > dump_task: 1 0 240 RR Kthread - Running > > 00> > > > > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: > > > > > Hi Yashvi, > > > > > > Please send the dump of this crash, using it you can find where the > code > > is > > > crashing. > > > > > > BR, > > > > > > Alan > > > > > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah > > > wrote: > > > > > > > Hello, > > > > > > > > I am attempting to retrieve data from a BMI270 sensor on an STM32H7 > > > board. > > > > > > > > However, when using the I2C scanner, a peculiar error is generated in > > > > Minicom. > > > > > > > > The error is dump_assert_info : current version: nuttx 12.8.0 > > > > > > > > > > > > Furthermore, when trying to configure (make menuconfig-> application > > > > configuration-> example).there no option of bmi270 > > > > > > > > Could you please assist me in resolving this issue? > > > > > > > > Thank you. > > > > > > > > > >
Re: Regarding bmi270
But I’m having a little trouble finding the BMI270 option in the application configuration examples. Thank you! On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah wrote: > > > Hello, > > By applying this, I was able to successfully execute the I2C scanner. > > Thank you! > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: > >> Hi Yashvi, >> >> You can enable the debug symbols to inspect where your code is crashing >> (the positions at LR: 0800d3b7 PC: 0800dcbe) >> >> Enable it in your menuconfig: >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols >> >> Then flash the new image and run: >> >> arm-none-eabi-addr2line -e nuttx 0800d3b7 >> arm-none-eabi-addr2line -e nuttx 0800dcbe >> >> Probably these LR and PC values will change for your new image, then >> modify >> the commands above to use the new values. >> >> BR, >> >> Alan >> >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah >> wrote: >> >> > Yes >> > >> > Details of error >> > >> > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 >> > 2025 0m >> > dump_assert_info: Assertion failed panic: at file: :0 task: >> > process: K5 >> > up_dump_register: R0: 4000541c R1: R2: 0048 R3: >> > 0001 >> > up_dump_register: R4: R5: R6: FP: >> > >> > up_dump_register: R8: SB: SL: R11: >> > >> > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: >> > 0800dcbe >> > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: >> > >> > up_dump_register: EXC_RETURN: >> > ffe9 >> > dump_stackinfo: User >> > Stack: >> > dump_stackinfo: base: >> > 0x38000208 >> > dump_stackinfo: size: >> > 2008 >> > dump_stackinfo: sp: >> > 0x380008b0 >> > stack_dump: 0x38000890: >> > 0d >> > stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c >> > 00 >> > stack_dump: 0x380008d0: 24f4 38000a48 >> > 39 >> > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 >> > 0f >> > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 >> > 08009b71 38 >> > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 >> > 7f >> > stack_dump: 0x38000950: 0030 380009e8 38000a48 >> > 08001e9d 00 >> > stack_dump: 0x38000970: 08001e25 080023b1 >> > 00 >> > stack_dump: 0x38000990: 08003ddc 0100 >> > 01 >> > stack_dump: 0x380009b0: 380001f0 0001 08003e33 >> > 380001f0 00 >> > stack_dump: 0x380009d0: 0001 0001 >> > 00 >> > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT >> > SIGMASK D >> > dump_task: 0 0 0 FIFO Kthread - Ready >> > 00> >> > dump_task: 1 0 240 RR Kthread - Running >> > 00> >> > >> > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: >> > >> > > Hi Yashvi, >> > > >> > > Please send the dump of this crash, using it you can find where the >> code >> > is >> > > crashing. >> > > >> > > BR, >> > > >> > > Alan >> > > >> > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah > > >> > > wrote: >> > > >> > > > Hello, >> > > > >> > > > I am attempting to retrieve data from a BMI270 sensor on an STM32H7 >> > > board. >> > > > >> > > > However, when using the I2C scanner, a peculiar error is generated >> in >> > > > Minicom. >> > > > >> > > > The error is dump_assert_info : current version: nuttx 12.8.0 >> > > > >> > > > >> > > > Furthermore, when trying to configure (make menuconfig-> application >> > > > configuration-> example).there no option of bmi270 >> > > > >> > > > Could you please assist me in resolving this issue? >> > > > >> > > > Thank you. >> > > > >> > > >> > >> >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
The goal is not to automatically merge PR, but only to avoid that some PRs that don't reach the maximum number of reviews be allowed to be merged. Typically, those who are most eager to impose new rules are not the same as those who are subject to them! BR, Alan On Wed, Feb 12, 2025 at 2:55 PM Sebastien Lorquet wrote: > Again, I will vote against this. Not that it matters if a majority wants > to approve it. > > This is a bypass of all other rules we're trying to enforce. > > If such situation arise, there are two cases: > > - either the submitter still cares and will yell at people to get it > approved > > - either it will be dropped entirely. > > I dont want to see unsupervised auto commits. > > The conditions listed in this point (no breakage, execution of tests, > etc) HAVE TO be verified. > > Sebastien > > > On 12/02/2025 17:14, Tiago Medicci Serrano wrote: > > Hi! > > > > Thanks, Tomek ;) > > > > So, rewriting 19: > > > > *19.* A PR may be *eligible* to be merged under the concept of *Lazy > > consensus* with the following conditions: > >- It affects only a single chip or board (no > > kernel/libs/upper-half drivers etc); > >- It implements a new feature (or app) that doesn't introduce > any > > breaking changes or backward incompatibility; > >- It didn't get the minimum of 4 reviewers after two weeks > (to be > > discussed); > > - At least one independent reviewer reviewed it; > >- It adheres to all other conditions. > > The PR's author should: > >- After a week (to be discussed) without any reviewers, send > an > > e-mail to the mailing list asking for more people to review it; > >- Explain why the PR can't be split into smaller PRs (if > > applicable); > >- Ask for the independent reviewer to merge it after two weeks > > without any other reviewers; > > *The (required) independent reviewer* is responsible for > checking > > if the PR matches the *Lazy Consensus* conditions and merging it. > > > > Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO > > escreveu: > > > >> On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano > >> wrote: > >>> Hi! > >>> Tomek, there is an important missing point about 19 (that is part of my > >>> proposal): > >>> > >>> 19. "Lazy consensus" is a situation where PR is auto-merged into the > upstream when not enough reviews are done in predefined time (i.e. > there are no minimum required positive reviews within two weeks time). > PR should initially be treated according the general rules (4 > independent reviewers); After a week without enough reviewers, a call > should be made on the > mailing list, explaining why the PR can't be split into smaller PRs; > After two weeks without any reviewers, we could merge if the above > conditions are met and we have at least one independent reviewer. This > may solve situation when we don't have enough people to review it (or > we are not interested in that). It prevents people from forking the > project just to be able to develop their stuff: *we* *really would not > like that*. The PR's author is still responsible for fixing some > bugs if found in the future. > >>> > >>> It's missing that a PR has to be *eligible *for requiring it and this > >>> includes some specific situations: > >>> - It should not affect more than one chip/board; > >>> - It applies to new features and apps that have no associated breaking > >>> changes and backward compatibility; > >>> - It requires at least one independent reviewer; > >>> - It requires an extensive testing section and proper documentation. > >>> > >>> These are *mandatory *conditions and we can vote it without it (this > was > >>> part of my considerations about *Lazy Consensus*). I would be against > >>> proposition 19 it if these requirements are missing. > >>> > >>> Can you please update proposition 19 and reconsider your vote based on > >> the > >>> requirements? > >> Hey there Tiago :-) > >> > >> This voting is to identify general rules that we all agree on already. > >> These points are supposed to be extract from our discussions. If I > >> missed some key points please add them here folks! For proposed rules > >> with doubts (0 or -1 votes) we should discuss more and update maybe > >> even finally reject them. > >> > >> On weekend we will gather and sum up the current vote results. Then > >> discussion will follow, where we may make clarifications, update > >> doubted rules, and vote again. The goal is to have common agreement on > >> the rules update. What we want to add and what form this is all up to > >> us. No one wants to enforce anything or create a monster that will > >> make our work harder, just a tool to help in review and code quality > >> improvement :-) > >> > >> If I provided incomplete information on proposition 19 then I am > >> sorry! Tiago you are the author, please send upd
Re: bin/ELF headers
Thanks Lwazi and Peter. By examining the data in the NuttX binary I have tentatively concluded that the binary, as stored as an MCUboot signed bootable image: * Has the 32 byte MCUboot header. This contains the address in RAM that the entire image in the flash slot, minus the 32 byte header, should be copied to * A further 32 bytes, that are perhaps a NuttX or gnu header or something, but I can't track done what is is specifically. Don't like loose ends, but hey ho * 4 byte reset handler address * 4 byte stack pointer value as appropriate for the reset handler * The address that I saw, 24 bytes in (i.e. 8 bytes after the reset handler address) is the address that the reset handler will finally jump to, after whatever it needs to do, I think? My debugger says this is the "Entry point"? * The NuttX Binary itself (i.e. pre MCUboot header stuff) does not include the "load address" so my debugger must get this from the loader script or map file etc. For my binary: * MCUboot load address is 0x20008000. This matches the gcc loader script. * Reset handler address is 0x200080e0 * Stack value is 0x20008240 * The "entry point" is 0x20008040 I can get my NuttX binary to run by either: * setting the stack value to 0 and running from 0x20008000 - but not 0x20008040. Or * setting the stack value to 0x200082e0 and running from 0x200080c0 I still admit to being confused and hate not 100% "knowing" what is going on. If anyone can aid my learning here it would be great, but I'll go with: * Copying the image to the address in the MCUboot header * Setting stack value and reset address to the first two bytes after the 32 bytes of unknown NuttX/gnu binary header. FYI, I have also been in dialogue with Microchip tech support who are helpful and willing, but I've not got the definitive from them as yet. I will update them with my current thinking and see what they say! On 11/02/2025 23:58, Peter Barada wrote: Tim, Common across bulk of ARM processors, the vector table starting at address 0x0 contains the 32-bit value of the stack pointer, address 0x4 contains the reset vector (i.e. where to start execution in supervisor state) and then the exception and IRQ vectors. On 12/02/2025 03:50, Lwazi Dube wrote: On Tue, 11 Feb 2025 at 18:59, Peter Barada wrote: Tim, Common across bulk of ARM processors, the vector table starting at address 0x0 contains the 32-bit value of the stack pointer, address 0x4 contains the reset vector (i.e. where to start execution in supervisor state) and then the exception and IRQ vectors. Only for cortex-m. Not true for armv7a and older.
Re: bin/ELF headers
Lwazi, My bad, but you could build Nuttx for armv7-a and disassemble its vector table to figure it out. Try configuring Nuttx for qemu-armv7a:nsh and build the image. Then using addr2line you can determine where the source for the vector table is via "addr2line -e nuttx 0x0" which returns "nuttx/arch/arm/src/armv7-a/arm_vectgortab.S:66". Looking in arm_vectortab.S shows _vector_start table which contains eight "ldr PC, " instructions(each assembling to 0xe59ff018 in my case) where contains the address to vector to. In this case the first entry jumps indirect of .Lresethandler to __start. From the symbol table you can find the value of __start (0x2e0 in my image) and from that find the source e.g. "addr2line -e nuttx 0x2e0" which points to "/home/peter/git/nuttx/nuttx-master/nuttx/arch/arm/src/armv7-a/arm_head.S:220". __start in arm_head.S you'll see code that does some initialization(to enambe MMU, etc) and jumps to .Lvstart where it setups the stack pointer to IDLE_STACK_TOP indirect from .Lstackpointer (IDLE_STACK_TOP). Hope this helps! On 2/11/25 22:50, Lwazi Dube wrote: On Tue, 11 Feb 2025 at 18:59, Peter Barada wrote: Tim, Common across bulk of ARM processors, the vector table starting at address 0x0 contains the 32-bit value of the stack pointer, address 0x4 contains the reset vector (i.e. where to start execution in supervisor state) and then the exception and IRQ vectors. Only for cortex-m. Not true for armv7a and older. -- Peter Barada peter.bar...@gmail.com
Re: [VOTE] NuttX Contributing Guidelines update 202502.
This "lazy consensus" seems hot topic, lets just gather the feedback votes for now to see how many +1 / 0 / -1 are out there, then we will discuss the details, everyone may have their own reasons and for sure we can express them freely here :-) Thanks :-) Tomek On Wed, Feb 12, 2025 at 7:21 PM Tiago Medicci Serrano wrote: > > Hi, > > Again, Sebastien, read it *carefully*. It seems you are not willing to do > it. > > It doesn't bypass anything: > > - either the submitter still cares and will yell at people to get it > > approved > > > * My proposal says explicitly about this:* > > The PR's author should: > > - After a week (to be discussed) without any reviewers, send an > > e-mail to the mailing list asking for more people to review it; > > > *Continuing:* > > I dont want to see unsupervised auto commits. > > > > The conditions listed in this point (no breakage, execution of tests, > > etc) HAVE TO be verified. > > > Neither do I! That's why there is the following rule: > > *The (required) independent reviewer* is responsible for checking > > if the PR matches the *Lazy Consensus* conditions and merging it > > > > *THE INDEPENDENT REVIEWER *(not the PR's author) is responsible for > checking and merging it. It requires *AT LEAST* one independent reviewer. > > So, if we were not able to have 4 reviewers *and* already asked for help. > Then we can try to check if it's *eligible*. > > Em qua., 12 de fev. de 2025 às 15:10, Alan C. Assis > escreveu: > > > The goal is not to automatically merge PR, but only to avoid that some PRs > > that don't reach the maximum number of reviews be allowed to be merged. > > > > Typically, those who are most eager to impose new rules are not the same as > > those who are subject to them! > > > > BR, > > > > Alan > > > > > > > > > > > > > > On Wed, Feb 12, 2025 at 2:55 PM Sebastien Lorquet > > wrote: > > > > > Again, I will vote against this. Not that it matters if a majority wants > > > to approve it. > > > > > > This is a bypass of all other rules we're trying to enforce. > > > > > > If such situation arise, there are two cases: > > > > > > - either the submitter still cares and will yell at people to get it > > > approved > > > > > > - either it will be dropped entirely. > > > > > > I dont want to see unsupervised auto commits. > > > > > > The conditions listed in this point (no breakage, execution of tests, > > > etc) HAVE TO be verified. > > > > > > Sebastien > > > > > > > > > On 12/02/2025 17:14, Tiago Medicci Serrano wrote: > > > > Hi! > > > > > > > > Thanks, Tomek ;) > > > > > > > > So, rewriting 19: > > > > > > > > *19.* A PR may be *eligible* to be merged under the concept of *Lazy > > > > consensus* with the following conditions: > > > >- It affects only a single chip or board (no > > > > kernel/libs/upper-half drivers etc); > > > >- It implements a new feature (or app) that doesn't > > introduce > > > any > > > > breaking changes or backward incompatibility; > > > >- It didn't get the minimum of 4 reviewers after two weeks > > > (to be > > > > discussed); > > > > - At least one independent reviewer reviewed it; > > > >- It adheres to all other conditions. > > > > The PR's author should: > > > >- After a week (to be discussed) without any reviewers, send > > > an > > > > e-mail to the mailing list asking for more people to review it; > > > >- Explain why the PR can't be split into smaller PRs (if > > > > applicable); > > > >- Ask for the independent reviewer to merge it after two > > weeks > > > > without any other reviewers; > > > > *The (required) independent reviewer* is responsible for > > > checking > > > > if the PR matches the *Lazy Consensus* conditions and merging it. > > > > > > > > Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO > > > > escreveu: > > > > > > > >> On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano > > > >> wrote: > > > >>> Hi! > > > >>> Tomek, there is an important missing point about 19 (that is part of > > my > > > >>> proposal): > > > >>> > > > >>> 19. "Lazy consensus" is a situation where PR is auto-merged into the > > > upstream when not enough reviews are done in predefined time (i.e. > > > there are no minimum required positive reviews within two weeks > > time). > > > PR should initially be treated according the general rules (4 > > > independent reviewers); After a week without enough reviewers, a > > call > > > should be made on the > > > mailing list, explaining why the PR can't be split into smaller > > PRs; > > > After two weeks without any reviewers, we could merge if the above > > > conditions are met and we have at least one independent reviewer. > > This > > > may solve situation when we don't have enough people to review it > > (or > > > we are not interested in that). It prevents people from forking the > > > project
Re: GSoC 2025
On Wed, Feb 12, 2025 at 7:45 PM Tiago Medicci Serrano wrote: > I would like to propose another topic: > * Enhancing on-demand paging algorithm on NuttX: > - It already has a rudimentary on-demand paging algorithm that allows > mapping the `data` memory on-demand ( > https://nuttx.apache.org/docs/latest/components/paging.html#kernel-build-implementation). > However, it doesn't allow loading applications from the read-only device > on-demand (it copies `text` area at once) and neither it contain an > algorithm to handle when physical memory allocation fails (like identifying > unused memory and writing to a flash partition, like the Linux's "swap > partition"). Thanks Tiago! :-) Do we have NuttX Mentors this year to register at Apache in the first place? The deadline seems to have passed but was extended, someone stepped down, I don't fully follow the conversations there :-P Without Mentors we will not be able to do any project and we should act quick in this area o_O https://community.apache.org/gsoc/ -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: GSoC 2025
Sorry I'm taking a break from GSoC this year :-) Last GSoC was horribly stressful, this year I'll focus on NuttX CI. I compiled some GSoC Tips here: https://github.com/apache/nuttx/issues/11957 Lup On Thu, Feb 13, 2025 at 8:05 AM Tomek CEDRO wrote: > On Wed, Feb 12, 2025 at 7:45 PM Tiago Medicci Serrano > wrote: > > I would like to propose another topic: > > * Enhancing on-demand paging algorithm on NuttX: > > - It already has a rudimentary on-demand paging algorithm that allows > > mapping the `data` memory on-demand ( > > > https://nuttx.apache.org/docs/latest/components/paging.html#kernel-build-implementation > ). > > However, it doesn't allow loading applications from the read-only device > > on-demand (it copies `text` area at once) and neither it contain an > > algorithm to handle when physical memory allocation fails (like > identifying > > unused memory and writing to a flash partition, like the Linux's "swap > > partition"). > > Thanks Tiago! :-) > > Do we have NuttX Mentors this year to register at Apache in the first > place? The deadline seems to have passed but was extended, someone > stepped down, I don't fully follow the conversations there :-P Without > Mentors we will not be able to do any project and we should act quick > in this area o_O > > https://community.apache.org/gsoc/ > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
Re: bin/ELF headers
On Wed, 12 Feb 2025 at 13:10, Tim Hardisty wrote: > Thanks Lwazi and Peter. By examining the data in the NuttX binary I have > tentatively concluded that the binary, as stored as an MCUboot signed > bootable image: > > * Has the 32 byte MCUboot header. This contains the address in RAM > that the entire image in the flash slot, minus the 32 byte header, > should be copied to > * A further 32 bytes, that are perhaps a NuttX or gnu header or > something, but I can't track done what is is specifically. Don't > like loose ends, but hey ho > This "header" is the first 32 bytes of your nuttx binary also known as the ARM vector table. The first eight instructions have opcode e59ff018. This can be seen in the objdump of the sama5d3-xplained nuttx file. I use "arm-none-eabi-objdump -drl nuttx" The line numbers and disassembly are interleaved. I added the comments starting with <-- nuttx: file format elf32-littlearm Disassembly of section .text: 20008000 <_vector_start>: <-- START running here. ADDRESS 0x20008000 _vector_start(): /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:66 20008000: e59ff018 ldr pc, [pc, #24] @ 20008020 <_vector_start+0x20> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:67 20008004: e59ff018 ldr pc, [pc, #24] @ 20008024 <_vector_start+0x24> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:68 20008008: e59ff018 ldr pc, [pc, #24] @ 20008028 <_vector_start+0x28> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:69 2000800c: e59ff018 ldr pc, [pc, #24] @ 2000802c <_vector_start+0x2c> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:70 20008010: e59ff018 ldr pc, [pc, #24] @ 20008030 <_vector_start+0x30> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:71 20008014: e59ff018 ldr pc, [pc, #24] @ 20008034 <_vector_start+0x34> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:72 20008018: e59ff018 ldr pc, [pc, #24] @ 20008038 <_vector_start+0x38> /nuttx/arch/arm/src/armv7-a/arm_vectortab.S:73 2000801c: e59ff018 ldr pc, [pc, #24] @ 2000803c <_vector_start+0x3c> 20008020: 20008240 .word 0x20008240 <--- ADDRESS loaded into PC by line 66 20008024: 200081c0 .word 0x200081c0 20008028: 200080a0 .word 0x200080a0 2000802c: 20008160 .word 0x20008160 20008030: 20008100 .word 0x20008100 20008034: 20008224 .word 0x20008224 20008038: 20008040 .word 0x20008040 2000803c: 20008220 .word 0x20008220 20008040 : arm_vectorirq(): <---snip> ... 20008240 <__start>: <--- The instruction at 0x20008000 jumps here __start(): /nuttx/arch/arm/src/armv7-a/arm_head.S:220 20008240: f10e00df cpsid if,#31 > * 4 byte reset handler address > * 4 byte stack pointer value as appropriate for the reset handler > * The address that I saw, 24 bytes in (i.e. 8 bytes after the reset > handler address) is the address that the reset handler will finally > jump to, after whatever it needs to do, I think? My debugger says > this is the "Entry point"? > * The NuttX Binary itself (i.e. pre MCUboot header stuff) does not > include the "load address" so my debugger must get this from the > loader script or map file etc. > > For my binary: > The load address 0x20008000 is where you should enter this image. (Not true for all boards) The instruction at the load address will jump to the correct location. NuttX should set the stack pointers. I can get my NuttX binary to run by either: > > * setting the stack value to 0 and running from 0x20008000 - but not > 0x20008040. Or > * setting the stack value to 0x200082e0 and running from 0x200080c0 > > I still admit to being confused and hate not 100% "knowing" what is > going on. > I respect people who admit they don't know _everything_. Unless you customized your startup code, copying your image to the correct address and running from 0x20008000 should be enough.
Re: Regarding bmi270
Is uORB really just a PX4 thing? Not NuttX? Or did NuttX adopt uORB too and I missed it? Just curious :-) On 12/02/2025 18:51, Alan C. Assis wrote: Hi Yashvi, BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) Just verify if the sensor was created correctly at /dev/uorb/ BR, Alan On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah wrote: Yes, I successfully completed the I2C scanner. After achieving success with I2C, I need to retrieve data from the BMI270. For that, I have done all the necessary configurations, and everything seems perfect. However, when I try to enable the BMI270 in the application configuration -> "Examples," there is no option for the BMI270 sensor. On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis wrote: Hi Yashvi, Please describe the issue you are facing. BTW, did the i2c scan find your BMI270? BR, Alan On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah wrote: But I’m having a little trouble finding the BMI270 option in the application configuration examples. Thank you! On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah wrote: Hello, By applying this, I was able to successfully execute the I2C scanner. Thank you! On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis wrote: Hi Yashvi, You can enable the debug symbols to inspect where your code is crashing (the positions at LR: 0800d3b7 PC: 0800dcbe) Enable it in your menuconfig: Build Setup ---> Debug Options ---> [*] Generate Debug Symbols Then flash the new image and run: arm-none-eabi-addr2line -e nuttx 0800d3b7 arm-none-eabi-addr2line -e nuttx 0800dcbe Probably these LR and PC values will change for your new image, then modify the commands above to use the new values. BR, Alan On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < yashvee...@gmail.com> wrote: Yes Details of error dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty Feb 12 2025 0m dump_assert_info: Assertion failed panic: at file: :0 task: process: K5 up_dump_register: R0: 4000541c R1: R2: 0048 R3: 0001 up_dump_register: R4: R5: R6: FP: up_dump_register: R8: SB: SL: R11: up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: 0800dcbe up_dump_register: xPSR: 2100 BASEPRI: CONTROL: up_dump_register: EXC_RETURN: ffe9 dump_stackinfo: User Stack: dump_stackinfo: base: 0x38000208 dump_stackinfo: size: 2008 dump_stackinfo: sp: 0x380008b0 stack_dump: 0x38000890: 0d stack_dump: 0x380008b0: 38000a48 0001 38000a48 24001e3c 00 stack_dump: 0x380008d0: 24f4 38000a48 39 stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 24f4 0f stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 08009b71 38 stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 0001 7f stack_dump: 0x38000950: 0030 380009e8 38000a48 08001e9d 00 stack_dump: 0x38000970: 08001e25 080023b1 00 stack_dump: 0x38000990: 08003ddc 0100 01 stack_dump: 0x380009b0: 380001f0 0001 08003e33 380001f0 00 stack_dump: 0x380009d0: 0001 0001 00 dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT SIGMASK D dump_task: 0 0 0 FIFO Kthread - Ready 00> dump_task: 1 0 240 RR Kthread - Running 00> On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis wrote: Hi Yashvi, Please send the dump of this crash, using it you can find where the code is crashing. BR, Alan On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < yashvee...@gmail.com wrote: Hello, I am attempting to retrieve data from a BMI270 sensor on an STM32H7 board. However, when using the I2C scanner, a peculiar error is generated in Minicom. The error is dump_assert_info : current version: nuttx 12.8.0 Furthermore, when trying to configure (make menuconfig-> application configuration-> example).there no option of bmi270 Could you please assist me in resolving this issue? Thank you.
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Again, I will vote against this. Not that it matters if a majority wants to approve it. This is a bypass of all other rules we're trying to enforce. If such situation arise, there are two cases: - either the submitter still cares and will yell at people to get it approved - either it will be dropped entirely. I dont want to see unsupervised auto commits. The conditions listed in this point (no breakage, execution of tests, etc) HAVE TO be verified. Sebastien On 12/02/2025 17:14, Tiago Medicci Serrano wrote: Hi! Thanks, Tomek ;) So, rewriting 19: *19.* A PR may be *eligible* to be merged under the concept of *Lazy consensus* with the following conditions: - It affects only a single chip or board (no kernel/libs/upper-half drivers etc); - It implements a new feature (or app) that doesn't introduce any breaking changes or backward incompatibility; - It didn't get the minimum of 4 reviewers after two weeks (to be discussed); - At least one independent reviewer reviewed it; - It adheres to all other conditions. The PR's author should: - After a week (to be discussed) without any reviewers, send an e-mail to the mailing list asking for more people to review it; - Explain why the PR can't be split into smaller PRs (if applicable); - Ask for the independent reviewer to merge it after two weeks without any other reviewers; *The (required) independent reviewer* is responsible for checking if the PR matches the *Lazy Consensus* conditions and merging it. Em qua., 12 de fev. de 2025 às 11:05, Tomek CEDRO escreveu: On Wed, Feb 12, 2025 at 2:13 PM Tiago Medicci Serrano wrote: Hi! Tomek, there is an important missing point about 19 (that is part of my proposal): 19. "Lazy consensus" is a situation where PR is auto-merged into the upstream when not enough reviews are done in predefined time (i.e. there are no minimum required positive reviews within two weeks time). PR should initially be treated according the general rules (4 independent reviewers); After a week without enough reviewers, a call should be made on the mailing list, explaining why the PR can't be split into smaller PRs; After two weeks without any reviewers, we could merge if the above conditions are met and we have at least one independent reviewer. This may solve situation when we don't have enough people to review it (or we are not interested in that). It prevents people from forking the project just to be able to develop their stuff: *we* *really would not like that*. The PR's author is still responsible for fixing some bugs if found in the future. It's missing that a PR has to be *eligible *for requiring it and this includes some specific situations: - It should not affect more than one chip/board; - It applies to new features and apps that have no associated breaking changes and backward compatibility; - It requires at least one independent reviewer; - It requires an extensive testing section and proper documentation. These are *mandatory *conditions and we can vote it without it (this was part of my considerations about *Lazy Consensus*). I would be against proposition 19 it if these requirements are missing. Can you please update proposition 19 and reconsider your vote based on the requirements? Hey there Tiago :-) This voting is to identify general rules that we all agree on already. These points are supposed to be extract from our discussions. If I missed some key points please add them here folks! For proposed rules with doubts (0 or -1 votes) we should discuss more and update maybe even finally reject them. On weekend we will gather and sum up the current vote results. Then discussion will follow, where we may make clarifications, update doubted rules, and vote again. The goal is to have common agreement on the rules update. What we want to add and what form this is all up to us. No one wants to enforce anything or create a monster that will make our work harder, just a tool to help in review and code quality improvement :-) If I provided incomplete information on proposition 19 then I am sorry! Tiago you are the author, please send updated proposition 19 text and note the old one is cancelled :-) Thanks!! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: GSoC 2025
I would like to propose another topic: * Enhancing on-demand paging algorithm on NuttX: - It already has a rudimentary on-demand paging algorithm that allows mapping the `data` memory on-demand ( https://nuttx.apache.org/docs/latest/components/paging.html#kernel-build-implementation). However, it doesn't allow loading applications from the read-only device on-demand (it copies `text` area at once) and neither it contain an algorithm to handle when physical memory allocation fails (like identifying unused memory and writing to a flash partition, like the Linux's "swap partition"). BR, Em seg., 10 de fev. de 2025 às 16:00, Alan C. Assis escreveu: > Hi Tomek, > > Normally we create entries in the GSoC and people interested in those > topics will contact us. > > I think for this year we have two suggestions: > > * Improving the NXBoot to evolve NuttX as Bootloader (maybe add commands > compatible with U-Boot) > * Syscalls Parameters Validation (not sure if it is an innovation or > interesting topic for GSoC) > > BR, > > Alan > > On Mon, Feb 10, 2025 at 3:30 PM Tomek CEDRO wrote: > > > On Wed, Jan 15, 2025 at 11:40 PM Tomek CEDRO wrote: > > > Google Summer of Code 2025 is coming, we already can and should > > > register ideas for NuttX :-) > > > > Okay, another idea that is quite important and security related is > > Syscalls Parameters Validation. > > > > We have several reports in this field. One is open and provided as > > public Issue. Another is closed and aims for CVE (responsible > > disclosure). Unfortunately the fix is left for us. > > > > https://github.com/apache/nuttx/issues/15178 > > > > We really need to fix this. There are example implementations in > > Zephyr and FreeRTOS that may server as reference points. Looks like a > > very interesting task for a diploma thesis. Do you think anyone who > > could be interested? > > > > -- > > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > > >
Re: Regarding bmi270
Hi Yashvi, BMI270 uses uORB, you need to use sensortest (CONFIG_SYSTEM_SENSORTEST) Just verify if the sensor was created correctly at /dev/uorb/ BR, Alan On Wed, Feb 12, 2025 at 3:23 PM 175 yashvi shah wrote: > Yes, I successfully completed the I2C scanner. > > After achieving success with I2C, I need to retrieve data from the BMI270. > For that, I have done all the necessary configurations, and everything > seems perfect. However, when I try to enable the BMI270 in the application > configuration -> "Examples," there is no option for the BMI270 sensor. > > On Wed, Feb 12, 2025, 11:43 PM Alan C. Assis wrote: > > > Hi Yashvi, > > > > Please describe the issue you are facing. BTW, did the i2c scan find your > > BMI270? > > > > BR, > > > > Alan > > > > On Wed, Feb 12, 2025 at 2:41 PM 175 yashvi shah > > wrote: > > > > > But > > > > > > I’m having a little trouble finding the BMI270 option in the > application > > > configuration examples. > > > > > > Thank you! > > > > > > On Wed, Feb 12, 2025, 11:05 PM 175 yashvi shah > > > wrote: > > > > > > > > > > > > > > > Hello, > > > > > > > > By applying this, I was able to successfully execute the I2C scanner. > > > > > > > > Thank you! > > > > > > > > On Wed, Feb 12, 2025, 9:16 PM Alan C. Assis > wrote: > > > > > > > >> Hi Yashvi, > > > >> > > > >> You can enable the debug symbols to inspect where your code is > > crashing > > > >> (the positions at LR: 0800d3b7 PC: 0800dcbe) > > > >> > > > >> Enable it in your menuconfig: > > > >> Build Setup ---> Debug Options ---> [*] Generate Debug Symbols > > > >> > > > >> Then flash the new image and run: > > > >> > > > >> arm-none-eabi-addr2line -e nuttx 0800d3b7 > > > >> arm-none-eabi-addr2line -e nuttx 0800dcbe > > > >> > > > >> Probably these LR and PC values will change for your new image, then > > > >> modify > > > >> the commands above to use the new values. > > > >> > > > >> BR, > > > >> > > > >> Alan > > > >> > > > >> On Wed, Feb 12, 2025 at 12:31 PM 175 yashvi shah < > > yashvee...@gmail.com> > > > >> wrote: > > > >> > > > >> > Yes > > > >> > > > > >> > Details of error > > > >> > > > > >> > dump_assert_info: Current Version: NuttX 12.8.0 1828d09b2a-dirty > > Feb > > > 12 > > > >> > 2025 0m > > > >> > dump_assert_info: Assertion failed panic: at file: :0 task: > > > > >> > process: K5 > > > >> > up_dump_register: R0: 4000541c R1: R2: 0048 R3: > > > >> > 0001 > > > >> > up_dump_register: R4: R5: R6: FP: > > > >> > > > > >> > up_dump_register: R8: SB: SL: R11: > > > >> > > > > >> > up_dump_register: IP: SP: 380008b0 LR: 0800d3b7 PC: > > > >> > 0800dcbe > > > >> > up_dump_register: xPSR: 2100 BASEPRI: CONTROL: > > > >> > > > > >> > up_dump_register: EXC_RETURN: > > > >> > ffe9 > > > >> > dump_stackinfo: User > > > >> > Stack: > > > >> > dump_stackinfo: base: > > > >> > 0x38000208 > > > >> > dump_stackinfo: size: > > > >> > 2008 > > > >> > dump_stackinfo: sp: > > > >> > 0x380008b0 > > > >> > stack_dump: 0x38000890: > > > > >> > 0d > > > >> > stack_dump: 0x380008b0: 38000a48 0001 38000a48 > 24001e3c > > > >> > 00 > > > >> > stack_dump: 0x380008d0: 24f4 38000a48 > > > > >> > 39 > > > >> > stack_dump: 0x380008f0: 3800fff8 38000a48 0001 38000a48 > 24f4 > > > >> > 0f > > > >> > stack_dump: 0x38000910: 0009 38000a58 0800bb13 38000a58 > > > > >> > 08009b71 38 > > > >> > stack_dump: 0x38000930: 38000a48 38000a58 0801ec48 08002075 > 0001 > > > >> > 7f > > > >> > stack_dump: 0x38000950: 0030 380009e8 38000a48 > > > > >> > 08001e9d 00 > > > >> > stack_dump: 0x38000970: 08001e25 080023b1 > > > > >> > 00 > > > >> > stack_dump: 0x38000990: 08003ddc 0100 > > > > >> > 01 > > > >> > stack_dump: 0x380009b0: 380001f0 0001 08003e33 > > > > >> > 380001f0 00 > > > >> > stack_dump: 0x380009d0: 0001 0001 > > > > >> > 00 > > > >> > dump_tasks:PID GROUP PRI POLICY TYPENPX STATE EVENT > > > >> > SIGMASK D > > > >> > dump_task: 0 0 0 FIFO Kthread - Ready > > > >> > 00> > > > >> > dump_task: 1 0 240 RR Kthread - Running > > > >> > 00> > > > >> > > > > >> > On Wed, Feb 12, 2025, 7:12 PM Alan C. Assis > > > wrote: > > > >> > > > > >> > > Hi Yashvi, > > > >> > > > > > >> > > Please send the dump of this crash, using it you can find where > > the > > > >> code > > > >> > is > > > >> > > crashing. > > > >> > > > > > >> > > BR, > > > >> > > > > > >> > > Alan > > > >> > > > > > >> > > On Wed, Feb 12, 2025 at 2:51 AM 175 yashvi shah < > > > yashvee...@gmail.com > > > >> > > > > >> > > wrote: > > > >> > > > > > >> > > >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
On Wed, Feb 12, 2025 at 5:15 PM Tiago Medicci Serrano wrote: > So, rewriting 19: > > *19.* A PR may be *eligible* to be merged under the concept of *Lazy > consensus* with the following conditions: > - It affects only a single chip or board (no > kernel/libs/upper-half drivers etc); > - It implements a new feature (or app) that doesn't introduce any > breaking changes or backward incompatibility; > - It didn't get the minimum of 4 reviewers after two weeks (to be > discussed); > - At least one independent reviewer reviewed it; > - It adheres to all other conditions. > The PR's author should: > - After a week (to be discussed) without any reviewers, send an > e-mail to the mailing list asking for more people to review it; > - Explain why the PR can't be split into smaller PRs (if > applicable); > - Ask for the independent reviewer to merge it after two weeks > without any other reviewers; > *The (required) independent reviewer* is responsible for checking > if the PR matches the *Lazy Consensus* conditions and merging it. -1: Still, sorry, I think this is too complex, contradicts idea 14 whatever final form it will have, and may create a loophole for "bad" code to enter the upstream that we are trying to fix right now. For now I am on the other side of spectrum, a safe defaults, safe-open didn't work well. I understand the reasons behind, maybe it reveals something constructive that we need, maybe in another form, maybe not now, for sure this idea needs more discussion :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
