On Fri, Jan 31, 2025 at 11:55 PM Gregory Nutt wrote:
> On 1/31/2025 3:52 PM, Tomek CEDRO wrote:
> > Greg I do not plan to reorganize existing _repositories_ and their
> > structure nor to reorganize the _project_ in any way :-)
>
> No, I was referring to the concept of putting all Issues under one
On Fri, Jan 31, 2025 at 10:56 PM Matteo Golin wrote:
> Given the discourse around breakages in synchronization between the
> nuttx-apps and nuttx repositories, I think I may begin adding new
> applications to `apps/sensors` but I will hold off on moving any already
> existing sensor examples. In t
On 1/31/2025 3:52 PM, Tomek CEDRO wrote:
Greg I do not plan to reorganize existing _repositories_ and their
structure nor to reorganize the _project_ in any way :-)
No, I was referring to the concept of putting all Issues under one
repository. That was the topic in 2019 and 2020. (although
Hi Tim,
I need to look into MCUboot loading strategies since in my case I was
executing from an internal flash drive, so there was no copying of the
image to RAM.
In general MCUboot expects an image to have a proper header and since ARM
vector table may have different requirements on alignment so
On Fri, Jan 31, 2025 at 10:09 PM wrote:
>
> On 2025-01-31 21:14:23, raiden00pl wrote:
> > > No, just be super careful designing API to "userspace" and once commited
> > it
> > stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> > well.
> > That's why we still have "creat" ins
Hello,
Given the discourse around breakages in synchronization between the
nuttx-apps and nuttx repositories, I think I may begin adding new
applications to `apps/sensors` but I will hold off on moving any already
existing sensor examples. In the coming days I expect to have something
functional f
On Fri, Jan 31, 2025 at 10:00 PM Gregory Nutt wrote:
> On 1/31/2025 1:45 PM, Tomek CEDRO wrote:
> > I prefer to have everything in one place.. to much everyday dispersion
> > if we keep things split in multiple places these will be ommited
> > probably?
> Since this is a decided and settle discussi
On 2025-01-31 21:14:23, raiden00pl wrote:
> > No, just be super careful designing API to "userspace" and once commited
> it
> stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> well.
> That's why we still have "creat" instead of "create". Or we have 3 poll
> APIs in
> Linux (
On Fri, Jan 31, 2025 at 3:15 PM raiden00pl wrote:
> > No, just be super careful designing API to "userspace" and once commited
> it
> stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
> well.
> That's why we still have "creat" instead of "create". Or we have 3 poll
> APIs in
On 1/31/2025 1:45 PM, Tomek CEDRO wrote:
I prefer to have everything in one place.. to much everyday dispersion
if we keep things split in multiple places these will be ommited
probably?
Since this is a decided and settle discussion that you are reopening,
you should probably familiarize yourse
On 1/31/2025 1:45 PM, Tomek CEDRO wrote:
Okay I can see that it is possible to put Issues and PRs from all of
our repos into a single project (i.e. Apache NuttX RTOS).
This was discussed and decided upon several years ago, before your time
with the project. Probably around 2019 or maybe early
> No, just be super careful designing API to "userspace" and once commited
it
stays. Forever. Bad APIs will remain. Posix does not remove bad APIs as
well.
That's why we still have "creat" instead of "create". Or we have 3 poll
APIs in
Linux (select/poll/epoll). You really want to change API, you b
On Fri, Jan 31, 2025 at 8:45 PM Tomek CEDRO wrote:
> Okay I can see that it is possible to put Issues and PRs from all of
> our repos into a single project (i.e. Apache NuttX RTOS). Do we really
> need 3 projects to separate rtos/apps/docs+www ? I think one place
> should be enough. But not deleti
Okay I can see that it is possible to put Issues and PRs from all of
our repos into a single project (i.e. Apache NuttX RTOS). Do we really
need 3 projects to separate rtos/apps/docs+www ? I think one place
should be enough. But not deleting anything yet, lets put all into
Apache NuttX RTOS project
On Fri, Jan 31, 2025 at 6:01 PM Sebastien Lorquet wrote:
> hello
> you are right, let's try:
> 12.8.0 -> configure broken
> 12.7.0 -> configure works
>
> apps is copied from master.
>
> CC: nsh_alias.c
> In file included from nsh_alias.c:39:
> nsh_console.h:191:18:error: 'LINE_MAX' undeclared her
On Fri, Jan 31, 2025 at 5:48 PM Sebastien Lorquet wrote:
> The interface between the two should be loose:
>
> -the build system, to get the code -> can be forced to be simple and
> fixed. call make -C $(APPS) app_code and nothing else.
> -the libc
>
> Apart from that I see no need to have a shared
On Fri, Jan 31, 2025 at 5:30 PM Sebastien Lorquet wrote:
> hello
> My proposal is:
> 1) define how the app build system is invoked and never move that
./tools/configure.sh ...
(g)make
That does not change :-)
Alternatively you can use CMake.
> 2) define that nuttx expects apps in a particular
[resend as I managed to mangle the Subject!]
Hi Petro - thanks for replying. Here're the relevant info and hope it is
not going to relult in a TLDR reponse...
* SAMA5D27C-D1G SoC, with 128Mbyte on-chip DDR2 SDRAM
* External GigaDevice 128Mbyte QSPI flash running at 80MHz
* App size is only
Hi Petro - thanks for replying. Here're the relevant info and hope it is
not going to relult in a TLDR reponse...
* SAMA5D27C-D1G SoC, with 128Mbyte on-chip DDR2 SDRAM
* External GigaDevice 128Mbyte QSPI flash running at 80MHz
* App size is only around 2 Mybtes at the moment, not likely to gr
I agree, here is an example change I had to do:
int itf_bring_up(int sd, struct ifreq *pifr)
{
int ret;
- pifr->ifr_flags = IFF_UP;
+ IFF_SET_UP(pifr->ifr_flags);
ret = ioctl(sd, SIOCSIFFLAGS, (unsigned long)pifr);
if (ret < 0)
{
@@ -263,7 +263,7 @@int itf_bring_up(
hello
you are right, let's try:
12.8.0 -> configure broken
12.7.0 -> configure works
apps is copied from master.
CC: nsh_alias.c
In file included from nsh_alias.c:39:
nsh_console.h:191:18:error: 'LINE_MAX' undeclared here (not in a
function); did you mean 'LINK_MAX'?
191 | char cn_lin
On 2025-01-31 17:34:48, raiden00pl wrote:
> How do you want to maintain compatibility between nuttx-apps and
> nuttx while both are active development projects, and what's more
> one of them is optional? It's not possible.
Same way as app/kernel compatibility is maintained in othes Unices like Linu
The interface between the two should be loose:
-the build system, to get the code -> can be forced to be simple and
fixed. call make -C $(APPS) app_code and nothing else.
-the libc
Apart from that I see no need to have a shared api.
What am I missing?
Sebastien
On 31/01/2025 17:34, raiden
On 2025-01-31 16:20:51, Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 3:35 PM wrote:
> > On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> > > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> > > wrote:
> > > > Of course I also tried with the commit before that one, and it didnt
> > > > work either
How do you want to maintain compatibility between nuttx-apps and
nuttx while both are active development projects, and what's more
one of them is optional? It's not possible.
It would be possible if we assumed that the API in NuttX is perfect
and will not require changes, which is not true. There
hello
My proposal is:
1) define how the app build system is invoked and never move that
2) define that nuttx expects apps in a particular file at a particular
place and never move that.
Also, enfore the use of the posix api everywhere. that should be enough...
the app/os limit is probably i
Dont loose too many time, reversing the commit already fixed the problem.
Or I'll charge you my own time :)
I think the two cancel anyway :)
It's a stm32f429 cpu, so you have all the stm32 "common" board stuff
inbetween.
host is debian 12 or wsl.
the problem happen just when running configu
On Fri, Jan 31, 2025 at 7:50 AM Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> wrote:
> > Of course I also tried with the commit before that one, and it didnt
> > work either.
>
> Sebastien, did you try the release packages? Does the problem occur in
> the release packa
Sebastien, please provide details on build configuration / how to
reproduce, we cannot reproduce the problem.
I think I will charge you hourly rate for playing the "deaf phone" as
your secretary :D :D
@cederom which defconfig is used? I try the master branch sim:nsh with
sed 4.9 without problem:
Thanks Raiden :-) This seems a kind of dump interface to existing
Issues and Pull Requests that are just displayed either as table,
boxes, or table with timeline aka roadmap.
I am used to Issues directly because any git web frontend has it. On
the other hand if we delete "project" we should not lo
Does Apache Foundation provide any project management tools?
I don't see anything interesting on https://infra.apache.org/services.html
If not, I guess we need to try with Github Projects.
pt., 31 sty 2025 o 14:22 Tomek CEDRO napisał(a):
> Hello world :-)
>
> As we discussed before we need a Roa
On Fri, Jan 31, 2025 at 3:35 PM wrote:
> On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> > On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> > wrote:
> > > Of course I also tried with the commit before that one, and it didnt
> > > work either.
> >
> > Sebastien, did you try the release packages?
Hello Tim,
Some time ago I was adding MCUboot support for SAMv7 family that should be
pretty similar to your system. If you can give some more description of
your use case: RAM and ROM config, does it have internal flash or external,
where the program is executed from, etc. maybe I will be able to
On Fri, Jan 31, 2025 at 3:10 PM Sebastien Lorquet wrote:
> Hi,
> On 31/01/2025 15:07, Tomek CEDRO wrote:
> > On Fri, Jan 31, 2025 at 2:54 PM Sebastien Lorquet
> > wrote:
> >> On 31/01/2025 13:56, Tomek CEDRO wrote:
> >>> Can you please report that Issue on GitHub? 🙂
> >> I dont have github accoun
On 2025-01-31 13:48:32, Tomek CEDRO wrote:
> On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet
> wrote:
> > Of course I also tried with the commit before that one, and it didnt
> > work either.
>
> Sebastien, did you try the release packages? Does the problem occur in
> the release packages?
>
Hi,
On 31/01/2025 15:07, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 2:54 PM Sebastien Lorquet wrote:
On 31/01/2025 13:56, Tomek CEDRO wrote:
Can you please report that Issue on GitHub? 🙂
I dont have github accounts anymore.
The mentioned commit was part of PR
https://github.com/apache/nuttx/
On Fri, Jan 31, 2025 at 2:54 PM Sebastien Lorquet wrote:
> On 31/01/2025 13:56, Tomek CEDRO wrote:
> > Can you please report that Issue on GitHub? 🙂
>
> I dont have github accounts anymore.
The mentioned commit was part of PR
https://github.com/apache/nuttx/pull/14552/files
It changes tools/proc
On 31/01/2025 13:56, Tomek CEDRO wrote:
Can you please report that Issue on GitHub? 🙂
I dont have github accounts anymore.
It's a custom board, we're not shipping devboards in industrial access
control.
Sebastien
Hello world :-)
As we discussed before we need a Roadmap and some sort of tools for
project management better than Wiki. I discovered GitHub Project that
we may try for this purpose.
https://github.com/orgs/apache/projects
This is also linked in top bar of our code repositories. Projects
seems t
On Fri, Jan 31, 2025 at 1:45 PM Sebastien Lorquet wrote:
> I have the default sed from debian 12
>
> slo@slolin:~/Sources/product-env/nuttx$ LANG=C sed --version
> sed (GNU sed) 4.9
> Packaged by Debian
> Copyright (C) 2022 Free Software Foundation, Inc.
> License GPLv3+: GNU GPL version 3 or late
On Fri, Jan 31, 2025 at 1:41 PM Sebastien Lorquet wrote:
> Of course I also tried with the commit before that one, and it didnt
> work either.
Sebastien, did you try the release packages? Does the problem occur in
the release packages?
Upstream master is for development purposes, things may get
Why, why should we suffer for trivial bugs like that? Life is hard enough.
I have the default sed from debian 12
slo@slolin:~/Sources/product-env/nuttx$ LANG=C sed --version
sed (GNU sed) 4.9
Packaged by Debian
Copyright (C) 2022 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 o
On 31/01/2025 13:16, Tomek CEDRO wrote:
On Fri, Jan 31, 2025 at 10:30 AM Sebastien Lorquet wrote:
Many problems arise when the nuttx and nuttx-apps are not in sync.
I always keep its masters in sync.. if there is no info on the website
we need to update documentation :-)
This is not possib
I have this problem on BSD too and need to replace with gsed (GNU Sed
variant). Would be nice to fix :-)
Tomek
On Fri, Jan 31, 2025 at 11:30 AM Sebastien Lorquet wrote:
>
> After git bisect over more than 2000 revisions, I found that this commit
> broke configure.sh for my board
>
>
> slo@slolin:
On Fri, Jan 31, 2025 at 10:30 AM Sebastien Lorquet wrote:
> Many problems arise when the nuttx and nuttx-apps are not in sync.
I always keep its masters in sync.. if there is no info on the website
we need to update documentation :-)
And I guess for the user its best to use release packages of n
Hi Sebastien,
The application repository should be independent from the main nuttx
> repo, right? and should continue to work even if nuttx is updated,
> right? Thats a reasonable expectation, right? but this is clearly not
> the case.
>
> This is a clear breakage of the os/app interface.
Yes, w
Reverting this does not seem to be a problem at all and fixes my problem.
Why was this added in the first place?
Maybe it increased some developer metric to show how productive they are.
We'll never know.
Sebastien
On 31/01/2025 11:29, Sebastien Lorquet wrote:
After git bisect over more than
Application.mk was not up to date. hah.
The application repository should be independent from the main nuttx
repo, right? and should continue to work even if nuttx is updated,
right? Thats a reasonable expectation, right? but this is clearly not
the case.
This is a clear breakage of the os/a
After git bisect over more than 2000 revisions, I found that this commit
broke configure.sh for my board
slo@slolin:~/Sources/ccv5-env/nuttx$ git bisect good
27685aa179ad7608394fb8a97e11ef532888a75d is the first bad commit
commit 27685aa179ad7608394fb8a97e11ef532888a75d
Author: yezhonghui
Date
Can you believe it?
After fixing all these apps so they talk with this OS, THE APPS BUILD
SYSTEM IS BROKEN
IN: /home/slo/Sources/product-env/product/apps/libapps.a ->
staging/libapps.a
install -m 0644 /home/slo/Sources/product-env/product/apps/libapps.a
staging/libapps.a
install: impossible
No rant here just facts, of the kind that makes my head explode.
Many problems arise when the nuttx and nuttx-apps are not in sync.
This should not happen, because nuttx sort-of promises an os/app
separation, and I dont think it is actually enforced.
I'm not talking about internal interfaces
51 matches
Mail list logo
