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
co
On Tue, Feb 11, 2025 at 8:37 AM Tomek CEDRO wrote:
>
> Hello world :-)
>
> As discussed extensively in various mailing list threads we have
> gathered all additional ideas for Contributing Guidelines update that
> should improve NuttX Code Quality and self-compatibility / long term
> maintenance.
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
How does the kernel know the killed thread is blocking in the driver's poll
method? Adding some flag in tcb_s for the special usage mayn't good.
BTW, there are many APIs that may block(e.g. write/read/send/recv), these
methods do not public callback to cancel the internal wait.
On Wed, Feb 12, 202
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.
As an example, nuttx/arch/arm/
Hello all.
I'm trying to understand the "header" bytes of a NuttX .bin file (ELF?),
so I can try and locate and use the ARM Cortex A (SAMA5D2) reset and
stack pointer vectors in an MCUboot image.
It seems that there are 32 bytes (after the MCUboot header) of a
repeating pattern (0xe59ff018)
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
Thank you for the reply Xiang and bringing the PRs to my attention.
If I understand the PRs, they don't quite satisfy my concern. In my use case,
an application is killed while blocked on a call to poll(). This results in a
call (initiated by the kernel) to the driver's close callback (which is
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 con
Could someone using CAN Bus review this modification:
https://github.com/apache/nuttx/pull/15809
BR,
Alan
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1 definitely shouldn't put runtime logs in the commit description
7. +1
8. +1
9. +1
10. -1, breaking changes shouldn't be unwelcome so long as they are
discussed an agreed upon by the community via the mailing list first. Some
criteria on what is considered suffic
Hi,
Thanks for the call.
The change looks reasonable as far as I am concerned.
It looks like it increases memory usage a little bit, but it's not dramatic.
I dont know if we have policies regarding memory usage statistics.
Micropython is quite strict about this.
Someone should double-check
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1 // this is something we need to improve, HW CI should confirm if a
PR is working
10. -1
In some cases breaking previous compatibility is necessary to evolution of
the project, but these breaking need to be discussed further in the
mainling lis
Hi,
What is the goal of lazy consensus? Faster merge? This is what we are
> trying to prevent I think.
Sorry Sebastien, it seems you didn't read my considerations.
It isn't about merging faster. Is about merging even after calling for help.
If we have a feature (likely a new feature) that does
What is the goal of lazy consensus? Faster merge? This is what we are
trying to prevent I think.
I promise you, if there is a loophole in the process, it will be exploited.
Better start strict and keep some room to adapt if we find problems,
than allowing an absence of review from the very st
Hi, just an additional comment:
Lazy consensus is exactly what lead to absence of any testing and breakages.
This *Lazy consensus *is just about the timeframe and the lack of 4
reviewers. The PR should be compliant with all other requirements
(description, testing, documentation etc).
My propos
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
wrote:
> Hello,
>
> I agree. Only bugfixes, criticity threshold to be determined, but new
> features seem unnecessary to me.
>
>
Hi!
I agree with almost every single point from Sebastien and Tomek:
Lazy consensus is exactly what lead to absence of any testing and breakages.
>
This isn't entirely true. *Lazy consensus *is very bad if it affects a lot
of people, but the Wi-Fi support for all Espressif chips was added with i
On Tue, Feb 11, 2025 at 12:37 AM Tomek CEDRO wrote:
> As discussed extensively in various mailing list threads we have
> gathered all additional ideas for Contributing Guidelines update that
> should improve NuttX Code Quality and self-compatibility / long term
> maintenance.
Thank you folks for
On Tue, Feb 11, 2025 at 12:40 PM Tiago Medicci Serrano
wrote:
> Two points that seem to be missing in the current *[VOTE] NuttX
> Contributing Guidelines update 202502.* thread:
>
> About commits...
>
> We were discussing splitting some changes into different PRs, adding the
> commit's message and
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
Hello,
I am adding a negative opinion to this.
Lazy consensus is exactly what lead to absence of any testing and breakages.
If something is not looked at, it MUST NOT be integrated silently. It
must be delayed until someone looks at it.
If no one acts, the mailing list can be called for acti
Hi all,
Here's my two cents.
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1 with a consideration:
Some changes might affect multiple boards and it may not be possible for a user
to test it all.
I think this is where input from reviewers come in by making sure, at least in
theory, that th
On Tue, Feb 11, 2025 at 9:55 AM Alin Jerpelea wrote:
> Hi all,
> there have been suggestions that we should create LTS releases
Lets see how our current code improvements work out in reality.. if
work as expected then there should be no need for LTS releases because
code should be self-compatible
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
escre
Hi,
Two points that seem to be missing in the current *[VOTE] NuttX
Contributing Guidelines update 202502.* thread:
About commits...
We were discussing splitting some changes into different PRs, adding the
commit's message and description, etc but I couldn't find anything (even on
Docs) that men
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
Hi,
1: +1
2: +1
3: +1
4: +1
5: +1
6: +1
7: +1
8: +1 I heavily recommend sending the documentation at the same PR.
Considering that PRs are as atomic as possible, the documentation should be
tightly linked with it. It would not create merge issues (at least not an
additional workload) and having t
1-4: +1
5: 0
*
Description for PR and commit are a given, how is anyone expected to understand
what you are trying to do (and why), without a description? That is what the
commit text field is for..
*
However, demanding build and run-time logs from downstream targets is not
feasible and I s
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
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
I propose that we start step by step
for our first LTS I aim to backport port the fixes for every quarter and
create a "." release in the same time we create normal releases
ex for 2025:
Match
13.0.0 LTS
Jun
13.0.1 LTS
13.1.0 regular
September
13.0.2 LTS
13.2.0 regular
December
13.0.3 LTS
13.3.0
Being cheeky here, but these are only good if we enforce these, and if
they are actually enforceable :) Self-certification is considered a joke
in many industrial places :)
Also, as an open source project, we are protected by the apache licence,
which says that we offer no warranty.
The euro
Hello,
This is an excellent idea.
How will we manage maintenance of these LTS releases? Some fixes are
likely to require some backports?
Sebastien
On 11/02/2025 09:54, Alin Jerpelea wrote:
Hi all,
there have been suggestions that we should create LTS releases
I propose that we mark every
Hello,
Thank you a million Tomek for having summed up everything.
1 +1
2 +1
3 +1
4 +1
5 +1
6 +1
7 +1
8 +1 same PR but different commits maybe?
9 +1 make sure tests are relevant to the function being tested and
provide useful coverage of the fix/feature.
10 +1 with allowing managed exc
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 wrote:
> Hi all,
>
> there have been suggestions that we should create LTS releases
>
> I propose that we mark every Q1 (m
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
1. +1
2. +1
3. +1
4. +1
5. +1
6. +1
7. +1
8. +1
9. +1
10. -1
Broken API, broken features and any other broken code should be removed
even if
it breaks some users code. Legacy code means more work for maintainers,
worse
code quality and inconvenience for users. It's always been like this in
NuttX,
1: +1 2: +1 3: +1 4: +1 5: +1 6: +1 7: +1 8: -1 documentation should be
provided at the same time as a separate PR with the same name and {2/2} to
indicate that they belong to the same PR. For LTS documentation may cause
merge issues and increase the maintainers workload 9: +1 10: +1 11: +1 PRs
sho
39 matches
Mail list logo
