Hi Tomek,
Try to compile using "make -j" it will reduce the time from minutes to
seconds (but will consume more power).
BR,
Alan
On Thu, Feb 6, 2025 at 10:54 PM Tomek CEDRO wrote:
> On Thu, Feb 6, 2025 at 7:30 PM Alan C. Assis wrote:
> > Something to keep in mind about this distributed (buil
Hi!
I didn't say that `citest` should test "everything": of course, peripherals
can't be tested (at least most of them), but it's the most basic test for
every architecture/chip/board because it can run `ostest` and other test
applications (`smp`, for instance). IMHO, it's the most important test
Support for peripherals in QEMU is very limited, and some peripherals
supported by QEMU are not available in new hardware. So the same
tests for qemu and real HW are just not possible for some targets.
Also configurations with all peripherals/features enabled are not possible
for many chips - we a
Hi!
citest config: I suggest to keep citest and hardware test absolutely
> separate. You want to be able to change one and not the other. Not the
> same components will be tested.
CI tests *include* HW testing...
For now, we have the `citest` defconfig for some boards and they are
intended to
On 2025-02-06 16:02:18, Matteo Golin wrote:
> I've got:
> - Raspberry Pi Pico
> - Raspberry Pi Pico W
> - XIAO RP2040
> - XIAO SAMD21
> - Raspberry Pi 4B
>
> And would also be willing to help test, provided it's easy enough for me to
> automate.
Just looked into my lost and forgotten drawer. As of
Hi,
a bit of a summary of the 10 previous messages
NDTS: NuttX Distributed Test System
NDHT: NuttX Distributed Hardware Test
nuttx-hwtest as we already have nuttx-apps
It's not original, I know lol
citest config: I suggest to keep citest and hardware test absolutely
separate. You want to b
Hi Tomek,
thanks for taking the initiative
I can put at least
Spresense
RP 2040
RP4b
Best regards
Alin
On Fri, 7 Feb 2025, 02:54 Tomek CEDRO, wrote:
> On Thu, Feb 6, 2025 at 7:30 PM Alan C. Assis wrote:
> > Something to keep in mind about this distributed (build) system:
> > Not everyone ha
On Thu, Feb 6, 2025 at 7:30 PM Alan C. Assis wrote:
> Something to keep in mind about this distributed (build) system:
> Not everyone has free electricity (solar panels) to run a computer server
> 24/7. And a solution where the server owner only runs it occasionally won't
> help.
> So we need to h
On Thu, Feb 6, 2025 at 10:02 PM Matteo Golin wrote:
> I've got:
> - Raspberry Pi Pico
> - Raspberry Pi Pico W
> - XIAO RP2040
> - XIAO SAMD21
> - Raspberry Pi 4B
> And would also be willing to help test, provided it's easy enough for me to
> automate.
Thanks Matteo! Our board base is growing :-)
I've got:
- Raspberry Pi Pico
- Raspberry Pi Pico W
- XIAO RP2040
- XIAO SAMD21
- Raspberry Pi 4B
And would also be willing to help test, provided it's easy enough for me to
automate.
On Thu, Feb 6, 2025 at 2:33 PM Tiago Medicci Serrano <
tiago.medi...@gmail.com> wrote:
> Hi!
>
> I wonder if tha
Hi!
I wonder if that be really bad if we added miminal citest / selftes to
> default configurations? Or this should stay minimal?
I think one `citest` defconfig is totally different from the minimal
configs. A minimal config is intended to be used by a user experimenting
with NuttX and `citest`
I think we can ask people to suggest some names and we can select the best
name.
Something to keep in mind about this distributed (build) system:
Not everyone has free electricity (solar panels) to run a computer server
24/7. And a solution where the server owner only runs it occasionally won't
h
On Thu, Feb 6, 2025 at 7:00 PM Tiago Medicci Serrano
wrote:
> Hi!
> Boards I Have
> I have at least two units of each supported Espressif SoC that can be
> allocated for testing:
> - ESP32
> - ESP32-S2
> - ESP32-S3
> - ESP32-C3
> - ESP32-C6
> - ESP32-H2
Thanks Tiago, noted! :-)
> DRUNX Proposal
Folks, Alan noticed there is already project named drunx :-(
https://github.com/alxolr/drunx
..and the name is not really serious :D For me its just a working
slur, so if you have a better idea for name please share :-)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Hi!
Boards I Have
I have at least two units of each supported Espressif SoC that can be
allocated for testing:
- ESP32
- ESP32-S2
- ESP32-S3
- ESP32-C3
- ESP32-C6
- ESP32-H2
DRUNX Proposal (at least for the first efforts)
That being said, I propose to start testing the `citest` defconfig (and,
On Thu, Feb 6, 2025 at 11:25 AM Sebastien Lorquet wrote:
> I can test (..)
On Thu, Feb 6, 2025 at 11:40 AM Tim Hardisty wrote:
> I have: (..)
Noted! TANK U =)
--
CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
I have:
* SAMA5D2 (Arm Cortex-A) Xplained EV board
* SAMA5D27-SOM1 EV board
* Custom board with SAMA5D27C-1G (128Mybte SDRAM) with TFT+TS, NOR
flash, SPI peripherals, I2C peripherals, USB, GPIO. All using NuttX
drivers.
I need to finish the project I'm on (which is still a few months' w
On Thu, Feb 6, 2025 at 10:01 AM raiden00pl wrote:
> Testing everything as a final goal is OK, but right now it's a waste of
> resources.
We are thinking ahead, planning, so anyone can attach whatever they
want / have / can port tests to, not to assume limits right from start
:-)
Yes we will star
I can test
-nucleo-H743ZI (MB1137 B-01)
-nucleo-H743ZI2
-STM32F492I-disco (MB1075 B-01 it has peripherals and external RAM)
-STM32L1 discovery (MP963 C)
-ESP32 devkit
-raspberry pi pico
-raspberry pi pico 2
-our custom boards using STM32F429, STM32H743ZI
I will consider acquiring more boa
Hi,
On 06/02/2025 10:00, raiden00pl wrote:
Chips with the same architecture use the same code,
so when we test a more advanced chip, we also test the code for a less
advanced chip.
Same code on slightly different chips is interesting because it
underpins the least documented differences betwe
> Quite the opposite :-) Testing few boards multiple times in the same
by different people may be a bit of waste, but its more about anyone
providing what they have at hand and I am sure different people from
around the world will have different boards, more people more boards
coverage, and we will
On Wed, Feb 5, 2025 at 8:25 AM raiden00pl wrote:
> But first we should determine what things we want to test, not what boards.
> Knowing what things we want to test, we can design test cases and possibly
> use what is already available.
This will be part of the drunx architecture, but I have crea
On Wed, Feb 5, 2025 at 3:12 PM Sebastien Lorquet wrote:
> This project is not even started yet :-)
Ekhem, its here already for some months in that form or another (see
Lup's CI and Dashboard, see my wall), not corporate style, not wearing
suits and expensive watches, not yet as we want, not yet a
On Wed, Feb 5, 2025 at 8:25 AM raiden00pl wrote:
> As mentioned earlier, testing all boards is pointless, especially since the
> project
> has very limited resources. Choosing a few boards that will allow us to
> test as many
> things as possible is the most optimal approach.
Quite the opposite :
I would say testing as much as possible is always a benefit.
I have worked for more than 15 years as an embedded specialist managing
mission critical code, and every bug we found later in the project was
in a test gap.
As my boss usually say, "If it's not tested, it doesnt work" and this
has
or starting to implement a monster that only prevents anyone from changing.
"No change anymore" can be implemented easier, just stop working and go on
vacation, haha. But no joke, that's also a way to send a project to death.
--
Hard- and Softwaredevelopment Consultant
Geschäftsführung: Simon Fil
Dear all,
each arch, driver and app tested once would be enough I think. A matrix can
help to identify test-gaps. Double testing is nice and triple testing is
not of benefit any more.
The goal should be to have fast access to results with transparency. I fear
starting to maintain a useless monste
I think we should test the most complete/complex boards from each arch. It
will cover most of the issues that could after other boards.
BR,
Alan
On Wed, Feb 5, 2025 at 4:23 AM raiden00pl wrote:
> As mentioned earlier, testing all boards is pointless, especially since the
> project
> has very l
As mentioned earlier, testing all boards is pointless, especially since the
project
has very limited resources. Choosing a few boards that will allow us to
test as many
things as possible is the most optimal approach.
But first we should determine what things we want to test, not what boards.
Know
On Tue, Feb 4, 2025 at 11:42 AM Luchian Mihai wrote:
> Hi!
> First thing, I'm fairly new to nuttx so I might be off subject but here is
> my hot take on this subject.
Welcome and have fun Mihai! :-)
> NuttX is offering support for a lot of boards, more than what DRUNX should
> require.
>
> Eg.
Hi!
First thing, I'm fairly new to nuttx so I might be off subject but here is
my hot take on this subject.
NuttX is offering support for a lot of boards, more than what DRUNX should
require.
Eg. stm32f3 family, offering support for all the boards would benefit the
boards more than the NuttX code
Hello world :-)
Lets keep the distributed build and runtime test environment
discussion in this mailing list thread.
Here is the discussion issue on GitHub:
https://github.com/apache/nuttx/issues/15730
Some things for start, at this point in time:
1. If anyone has better working name please s
32 matches
Mail list logo
