One of the ideas that came to mind when working with the x86 architecture
and
the ACRN hypervisor was that this setup could be a powerful tool for
automating
complex tests for NuttX. On a multicore x86 machine with a hypervisor, we
can
compile different NuttX images, run them simultaneously, and te
On Fri, Aug 9, 2024 at 3:00 PM Nathan Hartman wrote:
> I like Tomek's idea of testing Tiers, with Tier0 being "critical tests"
> that MUST pass, on all architectures and boards.
>
> I pike Alin's idea of an automatically updated test status report form,
> which can be viewed on GitHub.
>
> I recom
Yes, I think by default ostest should only print SUCCESS, FAIL or SKIPPED.
And in case of failure it could print the error message to quick
understanding of the issue.
For hardware testing something we can use is a 16-ports USB HUB with
individual port power controlled by uhubctl ( https://github.
I like Tomek's idea of testing Tiers, with Tier0 being "critical tests"
that MUST pass, on all architectures and boards.
I pike Alin's idea of an automatically updated test status report form,
which can be viewed on GitHub.
I recommend to list ALL supported boards in the report form, with "Need
T
On Fri, Aug 9, 2024 at 3:42 AM Nathan Hartman wrote:
> On Thu, Aug 8, 2024 at 8:58 PM Gregory Nutt wrote:
> > On 8/8/2024 6:48 PM, Nathan Hartman wrote:
> > > A dedicated "citest" program is a good idea!
> > I think that ostest could meet all of the needs of a "citest" program.
> > I just needs m
HI all ,
ostest is a nice first step on validating our RTOS but I think that having
a distributed testing farm on real HW will help us scale and diversify the
testing
My proposal is
1. have a build machine that builds every day all configs and provides the
binaries for download so that they can b
On Thu, Aug 8, 2024 at 8:58 PM Gregory Nutt wrote:
>
> On 8/8/2024 6:48 PM, Nathan Hartman wrote:
> > A dedicated "citest" program is a good idea!
> I think that ostest could meet all of the needs of a "citest" program.
> I just needs more control of the verbosity and format of the output. It
>
On 8/8/2024 6:48 PM, Nathan Hartman wrote:
A dedicated "citest" program is a good idea!
I think that ostest could meet all of the needs of a "citest" program.
I just needs more control of the verbosity and format of the output. It
already meets 95% of the requirement.
A dedicated "citest" program is a good idea!
The tests would need to be designed so that when a test passes, certain
variables would have certain values, which can be tested to produce the
PASS/FAIL result.
It will be tricky to design these tests, but it will be extremely valuable
for verifying t
On Thu, Aug 8, 2024, 06:02 Gregory Nutt wrote:
>
> On 8/7/2024 9:10 PM, yfliu2008 wrote:
> > ... if we had "ostest" based smoke testing coverage in our CI, those
> fake k230 issues can be prevented earlier.
>
> ostest would probably need some work to be useful in this case: ostest
> would need so
Yanfeng,
There is a basic automation test running on sim/qemu after the ci build
finish:
https://github.com/apache/nuttx/blob/master/tools/ci/cirun.sh
you can add more tests and boards as needed.
On Thu, Aug 8, 2024 at 11:10 AM yfliu2008 wrote:
> Alan,
>
>
> Just want to add that besides a testi
On 8/7/2024 9:10 PM, yfliu2008 wrote:
... if we had "ostest" based smoke testing coverage in our CI, those fake k230
issues can be prevented earlier.
ostest would probably need some work to be useful in this case: ostest
would need some kind of standard reporting in each test so that we wou
Hi Yanfeng and Alan: I have been running Daily OSTest for NuttX QEMU
RISC-V, hosted on GitHub Actions:
(1) OSTest for 32-bit QEMU RISC-V runs OK on GitHub Actions:
32-bit Flat Build (rv-virt:nsh):
https://github.com/lupyuen/nuttx-riscv64/actions/workflows/qemu-riscv-nsh.yml
32-bit Kernel Build (r
Hi Stuart,
Thank you very much for these ideas!
Really interesting this FPGA HW Test that EnjoyDigital created, I didn't
know about it.
This is the kind of link that should be included on our page.
I think a FPGA could be also used for that idea of the base board. It could
simulate many devices
This would be fantastic. enjoy-digital, the authors of Litex, already have
a HIL configuration for the arty_a7 and NuttX. Perhaps that could be used
with a little bit of collaboration.
What is the expected test frequency? Expecting a result back from every
runner on a PR may be problematic if ther
Hi Maciej,
Yes, using a computer to compile is also in our radar because it will
recreate real usage scenarios (if we only build the binary in the Github CI
we are limited to its toolchain version and libraries).
I think your suggestions are really good and it is aligned with what I have
in mind
Hi Gábor,
Amazing, let us know your idea and let us join forces to make it happen!
BR,
Alan
On Thu, Jul 18, 2024 at 5:29 PM Gábor Kiss-Vámosi
wrote:
> Oh, I see. Nice! I guess making it fully automated would be too good to be
> true.
>
> We test the supported boards manually, but we support a
Hi Michal,
I agree with you about the security side.
In fact my initial idea was using Raspberry Pi to do it using uhubctl see:
https://github.com/mvp/uhubctl (at bottom of page there are many projects
using it) with a 16 port USB HUB.
This way we could turn ON/OFF up to 16 boards and flash it o
Most of us have some spare PC around, such PC can have fresh Linux with a
gitlab-runner service and this gitlab-runner can build, flash and run
tests, a pipeline that gives positive or negative results.
With binaries already built it could just download instead.
I know that with GitLab this is mo
Oh, I see. Nice! I guess making it fully automated would be too good to be
true.
We test the supported boards manually, but we support and maintain much
less boards, and test them only before releases.
We started to work on something which can be related and seems like a good
collaboration opport
Hi
On 2024-07-18 16:14:20, Alan C. Assis wrote:
> We are creating a testing farm for NuttX to be integrated on our CI.
How is this going to work? Since, this seems like, tests will be conducted
on real hardware, I assume I would have to install some daemon at my home so
that CI could send commands
Hi Gábor,
Our idea is to do it automatically: the CI will build the binary and notify
the users to start the flashing process, test it and return the result.
We will need a board to do the flashing process (i.e. an ESP32 with
SWD/JTAG flashing emulation).
Does LVGL have farm board testing?
BR,
Hi,
In practice will it be manual testing by humans, or can you run some tests
automatically and remotely?
On Thu, Jul 18, 2024, 21:50 Alan C. Assis wrote:
> Actually I shared it publicly with modify permissions (danger mode, maybe
> it is better to use Comment option, so people can ask for inv
Actually I shared it publicly with modify permissions (danger mode, maybe
it is better to use Comment option, so people can ask for invitation)
BR,
Alan
On Thu, Jul 18, 2024 at 4:39 PM Kenneth Pettit wrote:
> Hi Alan,
>
> I guess you need to be invited to view that Google Doc?
>
> Ken
>
> On 7
Hi Alan,
I guess you need to be invited to view that Google Doc?
Ken
On 7/18/24 12:14 PM, Alan C. Assis wrote:
Hi Everyone,
We are creating a testing farm for NuttX to be integrated on our CI.
As you know, NuttX supports more than 300 boards and we need to test all
boards everytime someone m
Only my bad English, sometimes I try to do some direct translation, without
paying attention to the grammar rules.
"So let's map out which people have which development board".
BR,
Alan
On Thu, Jul 18, 2024 at 4:14 PM Alan C. Assis wrote:
> Hi Everyone,
>
> We are creating a testing farm for
Hi Everyone,
We are creating a testing farm for NuttX to be integrated on our CI.
As you know, NuttX supports more than 300 boards and we need to test all
boards everytime someone modifies our code base.
So, let's to map each person have each board, please include your name in
the front of each
27 matches
Mail list logo
