_
> > From: Tomek CEDRO
> > Sent: Tuesday, February 4, 2025 2:10:02 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: arm64 zynq-mpsoc was broken
> >
> > Thus the idea for DRUNX (Distributer Runtime and bUild for NuttX) Test
> > Env
___
> From: Tomek CEDRO
> Sent: Tuesday, February 4, 2025 2:10:02 AM
> To: dev@nuttx.apache.org
> Subject: Re: arm64 zynq-mpsoc was broken
>
> Thus the idea for DRUNX (Distributer Runtime and bUild for NuttX) Test
> Environment :-)
>
>
> --
> CeDeROM, SQ7MHZ, http:
o: dev@nuttx.apache.org
Subject: Re: arm64 zynq-mpsoc was broken
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 conversat
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 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
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
