How about to try out NuttX as bootloader for other OS as the idea for GSoC 2025?
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Yes, for hardware related problems a hardware verification seems
mandatory. Also we should define a minimal required test sequence
(i.e. run nsh, uname -a, ostest). Maybe this can be done with some
dedicated "selftest" configuration added to all boards?
This PR broke something:
https://github.com
Thus the idea for DRUNX (Distributer Runtime and bUild for NuttX) Test
Environment :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
On Mon, Feb 3, 2025, 14:35 Nathan Hartman wrote:
> I think we should restart the conversation about setting up a build and
> test farm of real hardware, with a
I like this plan of requiring hardware testing. Also, even if the PR may
contain enough information to be justified, it becomes really difficult for
anyone debugging to track down changes if the PR body doesn't have a
description of any testing or the change impact. If all the PRs follow the
enforc
Maybe we shouldn't merge PRs until at least one reviewer tests on real
hardware. It doesn't have to be the same board, but at least the same arch,
if it touches arch code. If it's in sched or something shared on all
architectures then it's okay to test on any arch. We would need to decide
how to ha
On 2025-02-03 22:45:29, Xiang Xiao wrote:
> The ai bot is a soft suggestion, not a rule from Lup introduces it
> initially.
> Many PR already contain the useful information, like these:
> https://github.com/apache/nuttx/pull/15749
> https://github.com/apache/nuttx/pull/15728
> But ai bot still comp
The ai bot is a soft suggestion, not a rule from Lup introduces it
initially.
Many PR already contain the useful information, like these:
https://github.com/apache/nuttx/pull/15749
https://github.com/apache/nuttx/pull/15728
But ai bot still complain the information isn't enough.
Even https://github
I think we should restart the conversation about setting up a build and
test farm of real hardware, with a diverse collection of boards and
processor architectures. It would be a good thing if we could have BOTH a
project-owned centralized farm AND a relatively easy way for individual
developers an
I can only guess that this change was verified on QEMU. And here is another
problem that introduces many bugs from Xiaomi: testing changes only on QEMU.
This approach has no chance of detecting all bugs and is inherently wrong.
Meaningful tests on QEMU are not possible. Even in cases where
virtual
Hi Kevin,
We have support for the sx127x family, so supporting sx1262 might not be
that different: you can take a look at
https://github.com/apache/nuttx/tree/master/drivers/wireless/lpwan/sx127x
(the upper-half driver) and
https://github.com/apache/nuttx/blob/master/boards/arm/stm32f0l0g0/nucleo-
The latest progress:
After a day of troubleshooting, I have confirmed that the issue was
caused by stack misalignment. The pull request #15437 changes
ARM64_CONTEXT_REGS from 36 to 37, resulting in the stack no longer being
16-byte aligned, when i changes ARM64_CONTEXT_REGS from 37 to 38
Hello
The other thread made the remark that this pull request was merged
https://github.com/apache/nuttx/pull/15437
However it appears that it was undocumented.
this problem was noticed by the ai bot
shortly after this it was approved by two people and merged
this is a breach of your own rul
The damn AI bot said:
*In short, the PR needs significant improvements before it can be
considered for merging.* It needs to be more thorough and provide the
necessary information for reviewers to evaluate the change effectively.
Follow the template more closely and fill in all the required se
13 matches
Mail list logo
