Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Gregory Nutt]

On 10/3/2024 7:07 PM, yfliu2008 wrote:

- Two kernel mode configs `nsbi` and `knsh` both show used memory growth after 
ostest.


I would consider memory leaks in core OS functions to be a major problem.

Re: Problems with STM32F7 and STM32H7 boards

[Roberto Bucher]

I found out the problem, with

CONFIG_NSH_DISABLE_EXIT=y

the exit(1) function in code correctly works otherwise the exit(1) call 
leads to:


_assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 
task: 0x80002b9


In my opinion it should be the opposite behavior...

Bye

Roberto



On 10/3/24 6:16 PM, michal.lyszc...@bofc.pl wrote:

On 2024-10-03 17:02:09, Roberto Bucher wrote:

I developed a python application called "pysimCoder" similar to XCos and
Simulink, which is able to generate control code for different targets
(Linux, Linux RT, Raspberry PI, NuttX and others). We have about 175 blocks
for the different targets already defined for inputs, outputs, functions,
sensors, actuators etc.

The 
Ok I see. So you expected exit() to work same as on, say, Linux. So that
app just exits back to the shell. According to function documentation
is should work like that


The exit() function causes normal process termination and the
least significant byte of status (i.e., status & 0xFF) is
returned to the parent (see wait(2)).

Don't know why it asserts, maybe you miss some config? Your best bet to
fix it is to put breakpoint at your exit() function, and step through the
code. Nuttx is exceptionally well documented in its C files, you will have
no problems following it.

Re: Problems with STM32F7 and STM32H7 boards

[Roberto Bucher]

Hi Alan

The function "exit(1)" in my code of the pysimCoder blocks will be 
called only if we set "y" to the configuration


CONFIG_NSH_DISABLE_EXIT=y

This configs means, in my opinion, that if exit is disabled, the 
function "exit" doesn't exist, but it seem that we have an opposite 
behaviour.


I'll check where this configuration is used.

Bye

Roberto

On 10/3/24 8:52 PM, Alan C. Assis wrote:

Hi Robert,

Did you identify the commit that changed the way exit(1) behaves?

BR,

Alan

On Thu, Oct 3, 2024 at 1:01 PM Roberto Bucher  wrote:


I developed a python application called "pysimCoder" similar to XCos and
Simulink, which is able to generate control code for different targets
(Linux, Linux RT, Raspberry PI, NuttX and others). We have about 175
blocks for the different targets already defined for inputs, outputs,
functions, sensors, actuators etc.

The 
On 2024-10-03 14:16:40, Roberto Bucher wrote:

_assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175

task:

0x80002b9

and this is related to the call of the function

exit(1);

in my code, for example if a device is not defined. The call to this

exit(1)

function leads to this assertion error.
Basically, what I have to do is only to stop my (generated) application

and

I think that it was ok in the past...

Any idea how to solve this?

I don't understand? What do you wanna solve? Hardfault? Well, then
don't call exit() function? I mean, if program cannot continue just
add proper log before doing call to exit() so next person does not
have to think hard what is going on. Better yet - if it's possible
to do, use static_assert()/COMPILE_TIME_ASSERT() to issue error
during compilation time that something is not defined.

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Lee, Lup Yuen]

+1 for Milk-V Duo S, Ox64, Star64 and PinePhone

= Milk-V Duo S Compiler
+ riscv-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv-none-elf-gcc
COLLECT_LTO_WRAPPER=/Users/luppy/xpack-riscv-none-elf-gcc-13.2.0-2/bin/../libexec/gcc/riscv-none-elf/13.2.0/lto-wrapper
Target: riscv-none-elf
Configured with:
/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/sources/gcc-13.2.0/configure
--prefix=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/application
--with-sysroot=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/application/riscv-none-elf
--with-native-system-header-dir=/include
--infodir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/info
--mandir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/man
--htmldir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/html
--pdfdir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/pdf
--build=aarch64-apple-darwin20.6.0 --host=aarch64-apple-darwin20.6.0
--target=riscv-none-elf --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libsanitizer --disable-libssp --disable-nls
--disable-shared --disable-threads --disable-tls --enable-checking=release
--enable-languages=c,c++,fortran
--with-gmp=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install
--with-newlib --with-pkgversion='xPack GNU RISC-V Embedded GCC arm64'
--with-gnu-as --with-gnu-ld --with-system-zlib --with-abi=ilp32
--with-arch=rv32imac --enable-multilib
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (xPack GNU RISC-V Embedded GCC arm64)

= Milk-V Duo S Configuration
+ ./tools/configure.sh milkv_duos:nsh

= Milk-V Duo S Size
+ riscv-none-elf-size nuttx
   text   databssdechex filename
 171858737  30160 202755  31803 nuttx

= Milk-V Duo S NSH Info and Free
NuttShell (NSH) NuttX-12.7.0
nsh> uname -a
NuttX 12.7.0 10e44f8915 Oct  3 2024 17:31:16 risc-v milkv_duos
nsh> free
 total   used   freemaxusedmaxfree  nused
 nfree
  Kmem:2061304  106802050624  360002050192 35
   4
  Page:   20971520 647168   20324352   20324352

= Ox64 Compiler
+ riscv-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv-none-elf-gcc
COLLECT_LTO_WRAPPER=/home/luppy/xpack-riscv-none-elf-gcc-13.2.0-2/bin/../libexec/gcc/riscv-none-elf/13.2.0/lto-wrapper
Target: riscv-none-elf
Configured with:
/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/sources/gcc-13.2.0/configure
--prefix=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/application
--with-sysroot=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/application/riscv-none-elf
--with-native-system-header-dir=/include
--infodir=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/x86_64-pc-linux-gnu/install/share/info
--mandir=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/x86_64-pc-linux-gnu/install/share/man
--htmldir=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/x86_64-pc-linux-gnu/install/share/html
--pdfdir=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/x86_64-pc-linux-gnu/install/share/pdf
--build=x86_64-pc-linux-gnu --host=x86_64-pc-linux-gnu
--target=riscv-none-elf --disable-libgomp --disable-libmudflap
--disable-libquadmath --disable-libsanitizer --disable-libssp --disable-nls
--disable-shared --disable-threads --disable-tls --enable-checking=release
--enable-languages=c,c++,fortran
--with-gmp=/__w/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/linux-x64/x86_64-pc-linux-gnu/install
--with-newlib --with-pkgversion='xPack GNU RISC-V Embedded GCC x86_64'
--with-gnu-as --with-gnu-ld --with-system-zlib --with-abi=ilp32
--with-arch=rv32imac --enable-multilib
Thread model: single
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (xPack GNU RISC-V Embedded GCC x86_64)

= Ox64 Configuration
+ ./tools/configure.sh ox64:nsh

= Ox64 Size
+ riscv-none-elf-size nuttx
   text   databssdechex filename
 175090   1609  33136 209835  333ab nuttx

= Ox64 NSH Info and Free
NuttShell (NSH) NuttX-12.7.0
nsh> uname -a
NuttX 12.7.0 10e44f8915 Oct  3 2024 17:30:13 risc-v ox64
nsh> free
 total 

Re: [VOTE] Apache NuttX 12.7.0 RC0 release

[Roberto Bucher]

+1 but I've to check more for nucleo-h745

Results:

arm-none-eabi-gcc -v
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 13.3.1 20240614 (15:13.3.rel1-1)

*nucleo-144:f746-pysim*
-rwxrwxr-x  1 bucher bucher  467588 Oct  3 13:25 nuttx
-rwxrwxr-x  1 bucher bucher  304456 Oct  3 13:25 nuttx.bin
-rw-rw-r--  1 bucher bucher 3524534 Oct  3 13:25 nuttx-export-12.7.0.tar.gz
-rw-rw-r--  1 bucher bucher  37 Oct  3 13:25 nuttx.manifest
-rw-rw-r--  1 bucher bucher 1836618 Oct  3 13:26 nuttx.map

nsh> free
 total   used   free    maxused    maxfree 
nused  nfree
  Umem: 218836  14300 204536  14672 201952 
56  4


Tested also with code generated from pysimCoder

*nucleo-h743zi2:pysim*
-rwxrwxr-x 1 bucher bucher 3734292 Oct  3 13:46 nuttx
-rwxrwxr-x 1 bucher bucher  320812 Oct  3 13:46 nuttx.bin
-rw-rw-r-- 1 bucher bucher 6461959 Oct  3 13:46 nuttx-export-12.7.0.tar.gz
-rw-rw-r-- 1 bucher bucher  902432 Oct  3 13:46 nuttx.hex
-rw-rw-r-- 1 bucher bucher  47 Oct  3 13:46 nuttx.manifest
-rw-rw-r-- 1 bucher bucher 2284044 Oct  3 13:46 nuttx.map

nsh> free
 total   used   free    maxused    maxfree 
nused  nfree
  Umem: 973860  18572 955288  18960 481824 
58  5

nsh>


*nucleo-h745zi:pysim_cm7*
-rwxrwxr-x 1 bucher bucher 3747168 Oct  3 13:32 nuttx
-rwxrwxr-x 1 bucher bucher  321204 Oct  3 13:32 nuttx.bin
-rw-rw-r-- 1 bucher bucher 6476945 Oct  3 13:32 nuttx-export-12.7.0.tar.gz
-rw-rw-r-- 1 bucher bucher  903528 Oct  3 13:32 nuttx.hex
-rw-rw-r-- 1 bucher bucher  47 Oct  3 13:32 nuttx.manifest
-rw-rw-r-- 1 bucher bucher 2296075 Oct  3 13:32 nuttx.map

nsh> free
 total   used   free    maxused    maxfree 
nused  nfree
  Umem: 678748  18652 660096  19040 481624 
58  4

nsh>

*but*:

Code generation from psimCoder using the exported library gives the 
following output*using the linker*:


arm-none-eabi-ld --entry=__start -nostdlib --gc-sections --cref 
-Map=/home/bucher/ToDo/NUTTX_release_test/nuttx/nuttx.map -L 
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/libs 
--entry=__start  -T 
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld \

  -o ../test  \
  nuttx_main.o test.o  nuttx_main-builtintab.o 
/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/lib/libpyblk.a --start-group 
-lsched -ldrivers -lboards -lc -lmm -larch -lm -lxx -lapps -lnet -lfs 
-lbinfmt -lboard 
/usr/lib/gcc/arm-none-eabi/13.3.1/thumb/v7e-m+dp/hard/libgcc.a --end-group
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:40: 
warning: redeclaration of memory region `itcm'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:41: 
warning: redeclaration of memory region `flash'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:42: 
warning: redeclaration of memory region `dtcm1'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:43: 
warning: redeclaration of memory region `dtcm2'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:44: 
warning: redeclaration of memory region `sram'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:49: 
warning: redeclaration of memory region `sram4'
arm-none-eabi-ld:/home/bucher/CACSD/pysimCoder/CodeGen/nuttx/nuttx-export/scripts/flash.ld:50: 
warning: redeclaration of memory region `bbram'

arm-none-eabi-ld: invalid length for memory region flash
### Created executable: test
arm-none-eabi-objcopy  -O ihex ../test ../test.hex

Exectuable seems to correctly work

bye

Roberto

On 10/3/24 12:05 PM, Lee, Lup Yuen wrote:

+1 for Milk-V Duo S, Ox64, Star64 and PinePhone

= Milk-V Duo S Compiler
+ riscv-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=riscv-none-elf-gcc
COLLECT_LTO_WRAPPER=/Users/luppy/xpack-riscv-none-elf-gcc-13.2.0-2/bin/../libexec/gcc/riscv-none-elf/13.2.0/lto-wrapper
Target: riscv-none-elf
Configured with:
/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/sources/gcc-13.2.0/configure
--prefix=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/application
--with-sysroot=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/application/riscv-none-elf
--with-native-system-header-dir=/include
--infodir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/info
--mandir=/Users/ilg/actions-runners/xpack-dev-tools/_work/riscv-none-elf-gcc-xpack/riscv-none-elf-gcc-xpack/build/darwin-arm64/aarch64-apple-darwin20.6.0/install/share/man
--htmldir=/Users/ilg/actio

Intros and offer for daily static analysis runs.

[Mark Hermeling]

Hello,

I work for CodeSecure, who builds and sells the CodeSonar static analysis tool 
that detects both coding style violations (think MISRA) as well as deep 
security vulnerability (think buffer overruns due to tainted data). Over the 
past while, we have been running CodeSonar on a couple of open source projects 
nightly and yesterday I added NuttX to that list.

These runs are driven from GitLab and I have a fork of the official repo here:
https://gitlab.com/codesonar/examples/nuttx

Repo is updated nightly and then CodeSonar is run on the changes and these 
changes are stored on a SaaS CodeSonar hub.

Two things I can do:

  *   I can send a daily email to the dev list with the new warnings of that 
day (if there were any changes). This is what I do with a couple of OSS 
projects.
  *   I can also give people from the community access to the CodeSonar hub to 
review the warnings there. This would provide you with the code browsing 
capabilities of CodeSonar as well and it would allow you to annotate warnings 
(High prio, low prio, false positives and so forth).
 *   Unfortunately, at this point in time the hub is not publicly 
accessible. Reach out to me at 
mhermel...@codesecure.com if you would like 
access.


I am open to other ideas as well. Right now, it only builds for 
raspberrypi-pico-w:nsh, I can certainly add other configurations.


(note: I had to make one change to arch/arm/src/common/Toolchain.defs and 
comment out line 308:
#ARCHOPTIMIZATION += --param=min-pagesize=0
as this was throwing an error with arm-none-eabi-gcc during compilation.


Regards,
Mark


The information contained in this e-mail and any attachments from CodeSecure, 
Inc may contain confidential and/or proprietary information, and is intended 
only for the named recipient to whom it was originally addressed. If you are 
not the intended recipient, any disclosure, distribution, or copying of this 
e-mail or its attachments is strictly prohibited. If you have received this 
e-mail in error, please notify the sender immediately by return e-mail and 
permanently delete the e-mail and any attachments.

Re: Problems with STM32F7 and STM32H7 boards

[Roberto Bucher]

Thanks to all!

The problem with the network is solved (I've installed ufw for another 
project, and the connection with the nuttx target failed!)


I've isolatedthe other problem related to

_assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 
task: 0x80002b9


and this is related to the call of the function

exit(1);

in my code, for example if a device is not defined. The call to this 
exit(1) function leads to this assertion error.
Basically, what I have to do is only to stop my (generated) application 
and I think that it was ok in the past...


Any idea how to solve this?

Thanks in advance

Roberto



On 10/1/24 5:30 PM, Tomek CEDRO wrote:

On Tue, Oct 1, 2024 at 1:09 PM Tomek CEDRO  wrote:

(..)
RC is the Release Candidate and is not the official release.. and yes
WE ARE MISSING THE nuttx-12.6.0 RELEASE TAG ON GITHUB!! :-)

Okay the nuttx-12.6.0 tag is now present, documentation updated, but
it is equivalent to 12.6.0-RC1 from what see so comparison with older
releases needs to be done to verify if / when / where the problem was
introduced in the code base :-)

Re: Intros and offer for daily static analysis runs.

[Alan C. Assis]

Hi Mark,
Thank you for letting us know about CodeSecure and CodeSonar static
analysis.

Some years ago I used PVS-Studio (info here:
https://acassis.wordpress.com/2017/07/13/using-pvs-studio-to-find-bugs-in-cc/
), but this kind of software coverage finds tons of false positives.

So, we will spend more time filtering what is really an issue and what is
not.

So, if you can share publicly what you have found it could be helpful.

BR,

Alan


On Thu, Oct 3, 2024 at 9:31 AM Mark Hermeling 
wrote:

> Hello,
>
> I work for CodeSecure, who builds and sells the CodeSonar static analysis
> tool that detects both coding style violations (think MISRA) as well as
> deep security vulnerability (think buffer overruns due to tainted data).
> Over the past while, we have been running CodeSonar on a couple of open
> source projects nightly and yesterday I added NuttX to that list.
>
> These runs are driven from GitLab and I have a fork of the official repo
> here:
> https://gitlab.com/codesonar/examples/nuttx
>
> Repo is updated nightly and then CodeSonar is run on the changes and these
> changes are stored on a SaaS CodeSonar hub.
>
> Two things I can do:
>
>   *   I can send a daily email to the dev list with the new warnings of
> that day (if there were any changes). This is what I do with a couple of
> OSS projects.
>   *   I can also give people from the community access to the CodeSonar
> hub to review the warnings there. This would provide you with the code
> browsing capabilities of CodeSonar as well and it would allow you to
> annotate warnings (High prio, low prio, false positives and so forth).
>  *   Unfortunately, at this point in time the hub is not publicly
> accessible. Reach out to me at mhermel...@codesecure.com mhermel...@codesecure.com> if you would like access.
>
>
> I am open to other ideas as well. Right now, it only builds for
> raspberrypi-pico-w:nsh, I can certainly add other configurations.
>
>
> (note: I had to make one change to arch/arm/src/common/Toolchain.defs and
> comment out line 308:
> #ARCHOPTIMIZATION += --param=min-pagesize=0
> as this was throwing an error with arm-none-eabi-gcc during compilation.
>
>
> Regards,
> Mark
>
> 
> The information contained in this e-mail and any attachments from
> CodeSecure, Inc may contain confidential and/or proprietary information,
> and is intended only for the named recipient to whom it was originally
> addressed. If you are not the intended recipient, any disclosure,
> distribution, or copying of this e-mail or its attachments is strictly
> prohibited. If you have received this e-mail in error, please notify the
> sender immediately by return e-mail and permanently delete the e-mail and
> any attachments.
>

Re: GSoC Final Report on mnemofs

[Alan C. Assis]

AFAIK the AI bot is used only to help identify things that are missing in
the PR, so it avoids asking users again and again to fill the Summary, etc.

BTW, I don't think simple things like that need Apache or PMC approval.

It is an open-source project after all and contributions are welcome!

But I'm glad we have you to disagree, it means we are doing the right thing
("Unanimity is always stupid." -- Nelson Rodrigues).

BR,

Alan

On Thu, Oct 3, 2024 at 5:50 AM Sebastien Lorquet 
wrote:

> Hi,
>
> I am now the owner of 4 Micron NAND chips and I am at the disposal of
> NuttX developers who want to test code to drive and use them.
>
>
> Tomek: It doesnt change a damn thing.
>
> If LLM are used to make up for contributor laziness that's even worse.
> You'll get unreliable slop when the proper thing to do is close these
> bogus requests and ask contributors to fill actual required information.
>
> Was the use of ai discussed and voted by the project? No need, I'll be
> the only one against it?
>
> Sebastien
>
>
> On 01/10/2024 13:01, Tomek CEDRO wrote:
> > On Tue, Oct 1, 2024 at 10:28 AM Sebastien Lorquet 
> wrote:
> >> (..)
> >> I will not be able to write new code. Specifically if it's now AI
> reviewed.
> > Sebastien the code is not reviewed by the AI it only provides initial
> > feedback on the PR and commit descriptions something we are constantly
> > repeating and asking some reporters to fill in with meaningful content
> > and what should be done correctly in the first place but its often not
> > :-) Humans are still reviewing, commenting, requesting changes,
> > approving, and merging the code no worries :-)
> >
>

Re: Problems with STM32F7 and STM32H7 boards

[michal . lyszczek]

On 2024-10-03 14:16:40, Roberto Bucher wrote:
> _assert: Assertion failed panic: at file: armv7-m/arm_hardfault.c:175 task:
> 0x80002b9
> 
> and this is related to the call of the function
> 
> exit(1);
> 
> in my code, for example if a device is not defined. The call to this exit(1)
> function leads to this assertion error.
> Basically, what I have to do is only to stop my (generated) application and
> I think that it was ok in the past...
> 
> Any idea how to solve this?
I don't understand? What do you wanna solve? Hardfault? Well, then
don't call exit() function? I mean, if program cannot continue just
add proper log before doing call to exit() so next person does not
have to think hard what is going on. Better yet - if it's possible
to do, use static_assert()/COMPILE_TIME_ASSERT() to issue error
during compilation time that something is not defined.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature

[Enhancement] Skip the CI Builds that don't match the Arch Label

[Lee, Lup Yuen]

Hi All: We're rolling out enhancements to the CI Workflow, to skip the
unnecessary NuttX Builds for PRs. Right now we wait for the CI Builds to
complete across All Architectures (Arm32, Arm64, RISC-V, Xtensa), even
though our PR modifies a Single Architecture. With the enhancements, the CI
Workflow will build only the Modified Architecture.

The solution uses the Arch Labels for PRs. Initially we target only the
Simple PRs: One Arch Label + One Size Label (e.g. "Arch: risc-v, Size: XS")
(1) For "Arch: arm / arm64": We build `other`, `arm-01`, `arm-02`, ...
(2) For "Arch: risc-v": We build `risc-v-01`, `risc-v-02`
(3) For "Arch: xtensa": We build `xtensa-01`, `xtensa-02`
(4) The above rules apply when the PR is Created or Modified
(5) When the PR is Merged: All targets shall be built
(6) Next Week: We'll add the rules for Simulator and x86_64

For Simple PRs: The CI Build Duration is reduced by roughly 15 mins (down
to 2 hours). Bottleneck is now in the macOS builds, we might skip them for
Simple PRs.

The updated CI code is explained here:
https://github.com/apache/nuttx/issues/13775

Lup

Re: [Enhancement] Skip the CI Builds that don't match the Arch Label

[Alan C. Assis]

Hi Lup,

This is a great improvement! Kudos!!!

BR,

Alan

On Thu, Oct 3, 2024 at 11:05 AM Lee, Lup Yuen  wrote:

> Hi All: We're rolling out enhancements to the CI Workflow, to skip the
> unnecessary NuttX Builds for PRs. Right now we wait for the CI Builds to
> complete across All Architectures (Arm32, Arm64, RISC-V, Xtensa), even
> though our PR modifies a Single Architecture. With the enhancements, the CI
> Workflow will build only the Modified Architecture.
>
> The solution uses the Arch Labels for PRs. Initially we target only the
> Simple PRs: One Arch Label + One Size Label (e.g. "Arch: risc-v, Size: XS")
> (1) For "Arch: arm / arm64": We build `other`, `arm-01`, `arm-02`, ...
> (2) For "Arch: risc-v": We build `risc-v-01`, `risc-v-02`
> (3) For "Arch: xtensa": We build `xtensa-01`, `xtensa-02`
> (4) The above rules apply when the PR is Created or Modified
> (5) When the PR is Merged: All targets shall be built
> (6) Next Week: We'll add the rules for Simulator and x86_64
>
> For Simple PRs: The CI Build Duration is reduced by roughly 15 mins (down
> to 2 hours). Bottleneck is now in the macOS builds, we might skip them for
> Simple PRs.
>
> The updated CI code is explained here:
> https://github.com/apache/nuttx/issues/13775
>
> Lup
>

Re: [Enhancement] Skip the CI Builds that don't match the Arch Label

[Alin Jerpelea]

Nice imrovement Lup!

Thank for looking into it

Best regards
Alin

On Thu, 3 Oct 2024, 16:16 Alan C. Assis,  wrote:

> Hi Lup,
>
> This is a great improvement! Kudos!!!
>
> BR,
>
> Alan
>
> On Thu, Oct 3, 2024 at 11:05 AM Lee, Lup Yuen  wrote:
>
> > Hi All: We're rolling out enhancements to the CI Workflow, to skip the
> > unnecessary NuttX Builds for PRs. Right now we wait for the CI Builds to
> > complete across All Architectures (Arm32, Arm64, RISC-V, Xtensa), even
> > though our PR modifies a Single Architecture. With the enhancements, the
> CI
> > Workflow will build only the Modified Architecture.
> >
> > The solution uses the Arch Labels for PRs. Initially we target only the
> > Simple PRs: One Arch Label + One Size Label (e.g. "Arch: risc-v, Size:
> XS")
> > (1) For "Arch: arm / arm64": We build `other`, `arm-01`, `arm-02`, ...
> > (2) For "Arch: risc-v": We build `risc-v-01`, `risc-v-02`
> > (3) For "Arch: xtensa": We build `xtensa-01`, `xtensa-02`
> > (4) The above rules apply when the PR is Created or Modified
> > (5) When the PR is Merged: All targets shall be built
> > (6) Next Week: We'll add the rules for Simulator and x86_64
> >
> > For Simple PRs: The CI Build Duration is reduced by roughly 15 mins (down
> > to 2 hours). Bottleneck is now in the macOS builds, we might skip them
> for
> > Simple PRs.
> >
> > The updated CI code is explained here:
> > https://github.com/apache/nuttx/issues/13775
> >
> > Lup
> >
>

Re: Problems with STM32F7 and STM32H7 boards

[michal . lyszczek]

On 2024-10-03 17:02:09, Roberto Bucher wrote:
> I developed a python application called "pysimCoder" similar to XCos and
> Simulink, which is able to generate control code for different targets
> (Linux, Linux RT, Raspberry PI, NuttX and others). We have about 175 blocks
> for the different targets already defined for inputs, outputs, functions,
> sensors, actuators etc.
> 
> The  into 3 functions, called from a main:
> 
> initialization, termination and interrupt service routine
> 
> The last one is called by a temporized thread.
> 
> If the initialization fails, the program must stop: till now (also in
> NuttX), this is realized by simply call the "exit(1)" function in the
> initialization procedure! Now (new?) in NuttX, when we call the "exit(1)"
> function we get the "Assertion failed panic" message, and no more the stop
> of the running control program, instead of return into the nsh application.
> 
> Of course, it is possible to exit from the main thread Using return) after
> controlling if the initialization function of a block is failed: but to
> implement this we, have to change the code of all the 175 blocks...
Ok I see. So you expected exit() to work same as on, say, Linux. So that
app just exits back to the shell. According to function documentation
is should work like that

> The exit() function causes normal process termination and the
> least significant byte of status (i.e., status & 0xFF) is
> returned to the parent (see wait(2)).

Don't know why it asserts, maybe you miss some config? Your best bet to
fix it is to put breakpoint at your exit() function, and step through the
code. Nuttx is exceptionally well documented in its C files, you will have
no problems following it.

-- 
.-.---.--.-.
| Michal Lyszczek | Embedded C, Linux |   Company Address|  .-. opensource |
| +48 727 564 419 | Software Engineer | Akacjowa 10a; 55-330 |  oo|  supporter |
| https://bofc.pl `.--: Brzezinka Sredzka PL | /`'\  & |
| GPG FF1EBFE7E3A974B1 | Bits of Code | NIP:   813 349 58 78 |(\_;/) programer |
`--^--^--^-'


signature.asc
Description: PGP signature

Re: GSoC Final Report on mnemofs

[Sebastien Lorquet]

Hi,

I am now the owner of 4 Micron NAND chips and I am at the disposal of 
NuttX developers who want to test code to drive and use them.



Tomek: It doesnt change a damn thing.

If LLM are used to make up for contributor laziness that's even worse. 
You'll get unreliable slop when the proper thing to do is close these 
bogus requests and ask contributors to fill actual required information.


Was the use of ai discussed and voted by the project? No need, I'll be 
the only one against it?


Sebastien


On 01/10/2024 13:01, Tomek CEDRO wrote:

On Tue, Oct 1, 2024 at 10:28 AM Sebastien Lorquet  wrote:

(..)
I will not be able to write new code. Specifically if it's now AI reviewed.

Sebastien the code is not reviewed by the AI it only provides initial
feedback on the PR and commit descriptions something we are constantly
repeating and asking some reporters to fill in with meaningful content
and what should be done correctly in the first place but its often not
:-) Humans are still reviewing, commenting, requesting changes,
approving, and merging the code no worries :-)

[VOTE] Apache NuttX 12.7.0 RC0 release

[Alin Jerpelea]

Hello all,
Apache NuttX 12.7.0 RC0 has been staged under [1] and it's
time to vote on accepting it for release. Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
required to pass.

The Apache requirements for approving a release can be found here [3]
"Before voting +1 PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that the
package meets the requirements of the ASF policy on releases."

A document to walk through some of this process has been published on
our project wiki and can be found here [4].

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [4])
[ ] -1 reject (explanation required)

Thank you all,
Alin Jerpelea

SCM Information:
  Release tag: nuttx-12.7.0-RC0
  Hash for the release nuttx tag: 10e44f8915a4e4dc016f117bc75973750c7e3edf
  Hash for the release nuttx-apps tag:
ac11e3cba9a1c9db02e0b9072e89e9113d4e776d

[1] https://dist.apache.org/repos/dist/dev/nuttx/12.7.0-RC0/
[2]
https://raw.githubusercontent.com/apache/nuttx/nuttx-12.7.0-RC0/ReleaseNotes
[3] https://www.apache.org/dev/release.html#approving-a-release
[4]
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release