Last week we upstreamed Milk-V Duo S SBC to NuttX Mainline. (Based on
Sophgo SG2000 RISC-V SoC) But NuttX Mainline changes every day. Will Milk-V
Duo S suffer “Software Bit Rot”? And fail to boot NuttX someday?
Let’s do Daily Automated Testing for NuttX on a Milk-V Duo S. Yep on the
Actual
rated with CI. We could find
> many issues that aren't detected currently. >>
>
> Thanks Alan, that's a great idea! Lemme find the best way to integrate
> Automated Testing into the CI, without breaking our PR Submissions.
>
> If a PR breaks the CI: Maybe we can
<< I think it could be very useful if integrated with CI. We could find
many issues that aren't detected currently. >>
Thanks Alan, that's a great idea! Lemme find the best way to integrate
Automated Testing into the CI, without breaking our PR Submissions.
If a PR break
e
> test NuttX on Ox64 automatically after building?
>
> Yes we can! With a little help from the Ox64 BL808 Emulator that we created
> last week. In this article, we fill in the missing pieces of our Ox64
> Emulator and run it for Automated Testing...
>
> (1) Booting NuttX i
Automated Testing...
(1) Booting NuttX in Supervisor Mode (instead of Machine Mode)
(2) Emulate OpenSBI for setting the System Timer
(3) Emulate the UART Interrupts for Console Input
(4) Execute everything with Expect Scripting (based on TCL)
(5) Which becomes our Daily Automated Testing (triggered every
This article explains how we do Automated Testing of every NuttX Release
for PineDio Stack BL604 RISC-V Board...
https://lupyuen.github.io/articles/auto2
Lup
I am wondering it's possible to test on the real hardware if we don't
get the donation from the commercial company.
Another option is to make the test software design so that it does not
depend on any particular hardware. I would like to be able to run the
tests on my desks using hardware
Do we have the enough resource to develop a full test suite from
scratch? Before we get the resource commitment, the realistic step is
integrate the test suite from other project. This isn't a bad idea
because NuttX is a ANSI/POSIX compliant OS, there is many test suite
to cover POSIX, C/C++ librar
> -Original Message-
> From: Gregory Nutt
> Sent: Wednesday, May 20, 2020 1:20 AM
> To: dev@nuttx.apache.org
> Subject: Re: Automated Testing
>
> >> Adding hardware raises complexities or design, manufacturing,
> >> distribution, and support. Not
Before we select any tools, I think we should first enumerate some
general requirements of the automated test. Here are a few things that
occur to me.
I think it should be pretty simple from the standpoint of features;
* Execute a sequence of test cases, broken out as test stops.
* It m
...; it would be better for hardware developers if they could run the
automated tests on the hardware that they have a vested interest in.
This deserves a few more words because I am contradicting myself: The
object of the automated test is to verify the OS (pure software). In
this case,
However, that when no where beyond Dave's personal use because there was
no way for regular people to get the board. The design was open so you
get everything you need to make your own, but that was it. So, from my
point of view, that was just wasted enthusiasm on my part.
Why? That effort c
On Tue, May 19, 2020 at 1:20 PM Gregory Nutt wrote:
> Or don't develop custom hardware. Use COTS (Commerical Off-The-Shelf) only.
That's the easiest (and possibly best) option.
Custom boards, if we ever get there, would serve multiple purposes,
one being testing, another being a reference platf
I don't think we need a rigid sequence of steps. I see nothing wrong
with skipping directly to 3, skipping 1 and 2. I see nothing wrong
with some people doing 3 while others are doing 4 concurrent. These
sequence is not useful.
What would be useful would be:
1. Selection of a common tool
On Tue, May 19, 2020 at 1:10 PM Gregory Nutt wrote:
> However, that when no where beyond Dave's personal use because there was
> no way for regular people to get the board. The design was open so you
> get everything you need to make your own, but that was it. So, from my
> point of view, that w
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple either.
This is why I suggested that we "grow" into it.
Or don't develop custom hardware. Use COTS (Commerical Off-The-Shelf) only.
(1) Perfect the current coding standar
On Tue, May 19, 2020 at 1:06 PM Gregory Nutt wrote:
> On Tue, May 19, 2020 at 12:57 PM Alan Carvalho de Assis
> wrote:
> > During the NuttX Workshop a friend (Thiago Costa Paiva) suggested
> > about the idea of creating a FPGA solution to validate NuttX hardware,
> > but his idea didn't take pla
During the NuttX Workshop a friend (Thiago Costa Paiva) suggested
about the idea of creating a FPGA solution to validate NuttX hardware,
but his idea didn't take place.
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple
On Tue, May 19, 2020, 9:57 AM Alan Carvalho de Assis
wrote:
> Hi Nathan,
>
> During the NuttX Workshop a friend (Thiago Costa Paiva) suggested
> about the idea of creating a FPGA solution to validate NuttX hardware,
> but his idea didn't take place.
>
> I think using a software simulator is a goo
During the NuttX Workshop a friend (Thiago Costa Paiva) suggested
about the idea of creating a FPGA solution to validate NuttX hardware,
but his idea didn't take place.
Adding hardware raises complexities or design, manufacturing,
distribution, and support. Not insumountble, but not simple
dware.
BR,
Alan
On 5/18/20, Nathan Hartman wrote:
> Moving this discussion from a 2020/05/17 thread titled:
> "Backporting Fixes [was: heap malloc when executing binary/elf file]"
>
> The discussion about automated testing begins at [1] where Greg
> asks whether we w
* The next tier could be an automated test suite that runs in a
simulator.
This would be accessible to the greatest numbers of developers and
contributors, because there's nothing to buy.
* The highest tier could be testing on a reference hardware board.
I think we need to assure th
On 5/18/2020 12:02 PM, Nathan Hartman wrote:
Moving this discussion from a 2020/05/17 thread titled:
"Backporting Fixes [was: heap malloc when executing binary/elf file]"
The discussion about automated testing begins at [1] where Greg
asks whether we want to invest in an exhaustive
Moving this discussion from a 2020/05/17 thread titled:
"Backporting Fixes [was: heap malloc when executing binary/elf file]"
The discussion about automated testing begins at [1] where Greg
asks whether we want to invest in an exhaustive functional test suite
to qualify releases.
I
24 matches
Mail list logo
