On Thu, Mar 9, 2023 at 2:34 PM KIKUCHI Takeyoshi
wrote:
> Thanks for your reply.
>
> I see, there are hard-coded devices...
>
> Then, would it be acceptable to make an entry in CONFIG that says, for
> example, "support automatic partition parsing" and if enabled,
> automatically parse the partiti
On Thu, Mar 9, 2023 at 2:14 AM Nathan Hartman wrote:
> I guess you have to assess the intended lifecycle of your product and
> over-provision your MCU accordingly to the expected rate of growth of the
> firmware.
I would stick to the smallest-possible-core-kernel-and-base-by-design
and put everyth
Would that be possible to set small symbolic price per board (i.e. $5
or something like that), maybe divide all stuff into 3 categories of
"small" "medium" "big" boards, so Greg could have kind of symbolic
"return of interest" for vacations and/or current expenses? :-)
--
CeDeROM, SQ7MHZ, http://
Thanks for your reply.
I see, there are hard-coded devices...
Then, would it be acceptable to make an entry in CONFIG that says, for
example, "support automatic partition parsing" and if enabled,
automatically parse the partition when a block device is registered?
I don't think the partition
On Thu, Mar 9, 2023 at 6:05 AM KIKUCHI Takeyoshi
wrote:
> Hi, All.
>
> The code to parse block device partitions is included (as well as the
> code to register partitions as devices), but it seems that the process
> to parse partitions is not called from the location where the block
> device is r
I have 90-95% of those boards.Sent from my Galaxy
Original message From: Brennan Ashton
Date: 3/8/23 7:29 PM (GMT-06:00) To:
dev@nuttx.apache.org Subject: Re: NuttX Hardware This is the sheet (a little
old now) that I had shared
out:https://docs.google.com/spreadsheets/d/1qM
This is the sheet (a little old now) that I had shared out:
https://docs.google.com/spreadsheets/d/1qMQV_CSN5Ka13_wr73QNo2Uh-NiSumjcwINuc0BkyIs
My goal had been to functional test as much as I could for that release,
and I did find a bunch of little things to fix that I think made for a
better re
Sometime ago I was talking with Brennan about listing the board that I
have here and he surprised me showing this board listing spreadsheet
on google docs. Maybe we can organize a listing to see who has board
X, Y, or Z and to make it possible to test NuttX on all possible
boards.
I have almos
On Wed, Mar 8, 2023 at 5:31 PM Gregory Nutt wrote:
>
> >> At some point NuttX will grow too large for deep embedded platforms.
> >>
> >>
> >> My concern exactly. Yes, POSIX compliance is super important because it
> >> provides portability: I regularly write a program and run it on PC and
> >> em
On Wed, Mar 8, 2023 at 7:53 PM Alan C. Assis wrote:
> Agreed! Let's keep it in a separated thread.
>
> Sometime ago I was talking with Brennan about listing the board that I
> have here and he surprised me showing this board listing spreadsheet
> on google docs. Maybe we can organize a listing to
Agreed! Let's keep it in a separated thread.
Sometime ago I was talking with Brennan about listing the board that I
have here and he surprised me showing this board listing spreadsheet
on google docs. Maybe we can organize a listing to see who has board
X, Y, or Z and to make it possible to test N
On Wed, Mar 8, 2023 at 11:31 PM Gregory Nutt wrote:
> Related: This would be an issue for people who have to support a product
> for an extended life. In the early 2010's, for example, there were
> products using NuttX based on MCUs with 32Kb of FLASH memory. I suspect
> those would already be in
On Wed, Mar 8, 2023 at 11:14 PM Nathan Hartman wrote:
> On Wed, Mar 8, 2023 at 4:02 PM Sebastien Lorquet
> wrote:
> > You are right about posix compliance, this is a valuable goal, but at
> > the same time it raises the hard remark:
> > At some point NuttX will grow too large for deep embedded pla
This needs to be in its own thread.
Your collection of boards probably got some historical value.
Sebastien
On 3/8/23 23:31, Gregory Nutt wrote:
Slightly different topic: I have almost every board that ever ran
NuttX from about 2005 through 2020 or so. That is probably several
hundred board
At some point NuttX will grow too large for deep embedded platforms.
My concern exactly. Yes, POSIX compliance is super important because it
provides portability: I regularly write a program and run it on PC and
embedded with almost no changes. This is one of the big selling points of
NuttX f
On Wed, Mar 8, 2023 at 4:02 PM Sebastien Lorquet
wrote:
> You are right about posix compliance, this is a valuable goal, but at
> the same time it raises the hard remark:
>
> At some point NuttX will grow too large for deep embedded platforms.
My concern exactly. Yes, POSIX compliance is super
Hi, All.
The code to parse block device partitions is included (as well as the
code to register partitions as devices), but it seems that the process
to parse partitions is not called from the location where the block
device is registered.
(There is a function called "register_blockpartition",
Okay, so Gregory honored me with the maintenance of nuttx.com and
nuttx.org domains, thank You Greg!! :-)
Both (www.)nuttx.org and (www.)nuttx.com now redirects to
https://nuttx.apache.org :-)
I have also created a dedicated hosting account with MySQL / CGI / PHP
/ Python / Ruby capabilities, so
On Wed, Mar 8, 2023 at 7:16 PM Alan C. Assis wrote:
> Problem is that we don't have enough reviewers.
I was recently invited to the PMC, thank you, this is a great honour,
and obligation, I will try to act as best I can to support you folks..
but this is really lots of everyday work from what I ca
You are right about posix compliance, this is a valuable goal, but at
the same time it raises the hard remark:
At some point NuttX will grow too large for deep embedded platforms.
That may or may not be true. Certainly NuttX has outgrown most old
architectures with 16-bit address space lim
You are right about posix compliance, this is a valuable goal, but at
the same time it raises the hard remark:
At some point NuttX will grow too large for deep embedded platforms.
Sebastien
On 3/8/23 21:41, Gregory Nutt wrote:
Historically, whenever we find a POSIX issue we have always fixed i
Historically, whenever we find a POSIX issue we have always fixed it in
order to as compliant as possible. In the hierarchy of values, POSIX is
probably at the top of the list and well above personal preferences and
novel solutions. In the name of POSIX compliance, we have eliminated
architec
On Wed, Mar 8, 2023 at 3:20 PM Gregory Nutt wrote:
> POSIX defines the TERMIOS options and, I suspect that those TERMIOS
> options are required, not optional (need to check that). If that is
> true, then there should be no CONFIG_SERIAL_TERMIOS option; it should
> always be enabled.
Unless the
POSIX defines the TERMIOS options and, I suspect that those TERMIOS
options are required, not optional (need to check that). If that is
true, then there should be no CONFIG_SERIAL_TERMIOS option; it should
always be enabled.
On 3/8/2023 2:15 PM, Nathan Hartman wrote:
On Wed, Mar 8, 2023 at 2:
Hi,
This is a good idea to better follow posix.
This is typically the kind of stuff that would have deserved a message
on the dev list to say:
Hey friends we are improving terminals, expect bugs because it's hard to
get right, oh btw apps need to be updated too, otherwise strange things
m
On Wed, Mar 8, 2023 at 2:26 PM Xiang Xiao wrote:
>
> Since the code to handle the special process is very small, is it better to
> always allow application change ECHO and OPOST through TCSETS? So, the
> special function or program can disable ECHO/OPOST programmatically.
Only if termios suppo
On Thu, Mar 9, 2023 at 3:07 AM Gregory Nutt wrote:
>
> I imagine that this is occurring because readline also echos the
> input:
>
>
>
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
> The low-level serial driver should not e
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
The low-level serial driver should not echo just because /isconsole /is
true. Console echo is always handled by the application.
On Thu, Mar 9, 2023 at 2:17 AM Gregory Nutt wrote:
>
> >> I imagine that this is occurring because readline also echos the input:
> >>
> >>
> >>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
> >>
> >> The low-level serial driver should not echo just bec
Hi,
I think that some key information is missing like what is the NuttX version
used. Is it mainline or some release or custom.
Best regards,
Petro
It would be helpful to understand where and why the crash occurs too.
You can get that information by analyzing the stack. See
https://cwik
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
The low-level serial driver should not echo just because /isconsole /is
true. Console echo is always handled by the application. I
Hi Lwazi,
It is not sarcarm, I'm talking about facts.
Also I didn't say Sebastien points aren't valid, but is diverting from
the real issue.
The issue is not if the discussion is happening here or there, the
Problem is that we don't have enough reviewers.
So, first step is that NuttX needs to i
On Wed, Mar 8, 2023 at 12:09 AM Gregory Nutt wrote:
> I imagine that this is occurring because readline also echos the input:
>
>
> https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_common.c#L644
>
> The low-level serial driver should not echo just because /isconsole /is
>
Hi,
I think that some key information is missing like what is the NuttX version
used. Is it mainline or some release or custom.
Best regards,
Petro
On Wed, Mar 8, 2023, 7:24 PM Xiang Xiao wrote:
> On Thu, Mar 9, 2023 at 12:57 AM Simon Filgis <
> si...@ingenieurbuero-filgis.de>
> wrote:
>
> > D
>From: Gregory Nutt
>Sent: 03 March 2023 19:03
>
>On 3/3/2023 12:56 PM, Gregory Nutt wrote:
>> On 3/3/2023 12:36 PM, Nathan Hartman wrote:
>>> On Fri, Mar 3, 2023 at 1:07 PM Tim Hardisty wrote:
- I have enabled CONFIG_SIGKILL_ACTION to allow me to ctrl-c from
the console if the app is m
ok. thank you for the info.
hopefully i will have some time to spend on these boards next month.
On Thu, Mar 9, 2023 at 2:22 AM Brennan Ashton wrote:
>
> I do have a lot of changes in a local branch, but have not had much time to
> focus on this. The early stage bring up is not well documented an
On Wed, Mar 8, 2023 at 6:08 PM Tomek CEDRO wrote:
> Master branch can have some things that will not work. No one is able
> to predict everything. It is still possible to revert changes or
> redirect them in a good "backward compatible" way with a new feature.
Just a note: There are two approaches
On Thu, Mar 9, 2023 at 12:57 AM Simon Filgis
wrote:
> Dear all,
>
> I switched to Manjaro a few weeks ago. Now I'm trying to build NuttX - of
> course.
>
> This packages where necessary so far:
>
> sudo pacman -S ncurses base-devel gmp mpfr libisl elfutils expat
> lib32-gcc-libs uboot-tools unzip
I do have a lot of changes in a local branch, but have not had much time to
focus on this. The early stage bring up is not well documented and fairly
challenging. You can find my notes here as well.
https://btashton.github.io/bl808-notes/
If you would like to collaborate on this that would be aw
On Wed, Mar 8, 2023 at 10:05 PM Sebastien Lorquet
wrote:
> I dont think your point of view is very realistic. You seem to be
> turning the situation into something that pleases you but is not really
> compatible with what can be observed from outside.
>
> In the archive for 2023 there are 2035 to
On Wed, Mar 8, 2023 at 5:37 PM Lwazi Dube wrote:
> On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote:
> >
> > Sebastien,
> >
> > If all the discussions that happens on github start to happen here,
> > this mailing list will be just like the nuttx-commits mailing list.
>
> I'll take this as sarcasm
Hi,
I am really certain "people" have the best intention, but it would be
even better if they shared these with the rest of the community.
And I am not talking about code review.
You cant review code if you dont know there IS serious code to review.
And we dont need to review every typo.
I
Dear all,
I switched to Manjaro a few weeks ago. Now I'm trying to build NuttX - of
course.
This packages where necessary so far:
sudo pacman -S ncurses base-devel gmp mpfr libisl elfutils expat
lib32-gcc-libs uboot-tools unzip
# Install genromfs as per PX4
wget
https://sourceforge.net/projec
hi,
i recently received a few small boxes labelled "Sipeed M1S Dock"
and i'm interested in nuttx support of the board.
google suggested me Brennan's wip tree.
https://github.com/btashton/incubator-nuttx/tree/bl808/bringup
Brennan, is it the latest? or do you have any unpushed changes?
On Wed, 8 Mar 2023 at 09:55, Alan C. Assis wrote:
>
> Sebastien,
>
> If all the discussions that happens on github start to happen here,
> this mailing list will be just like the nuttx-commits mailing list.
I'll take this as sarcasm. Sebastien is making a lot of valid points,
in good faith, and b
This whole thread really bums me out. We really should be assuming people
are acting with best intentions, rather than accusing of ulterior motives.
If there are changes that you have concerns about people tend to be very
reasonable about explaining and if we need to revert something or change
some
I think that there are two different kinds of discussion that we need to
have and these are probably best done in different forums.
/*Black Box*/
By black box I mean the externally observed behavior and characteristics
of the OS: Interfaces, performance, driver facilities, build changes
etc.
hi,
let me repeat my concerns about the recent addition of WASM module
build support here
as i think it warrants a ML discussion.
https://github.com/apache/nuttx-apps/pull/1609#issuecomment-1460411089
honestly speaking, i feel the feature is halfly-baked at best. maybe
it's a misfeature.
* i fee
but, Github PRs and discussion there is not public?
And also the commits, messages and discussions are not being archived?
So, what exactly is the problem?
to me it seems more like you are trying to justify your failure to
follow the project and discuss it in the community.
Obs: I feel like I'
I tend to disagree.
You have extreme views that all commits need to be discussed. That is false.
What need to be discussed is much subtle.
We need to have discussion whenever ANYONE has a doubt about something
that is happening on github BEFORE this is committed.
Xiaomi (and other companies
On 3/8/2023 9:17 AM, Gregory Nutt wrote:
``There's a saying here that "if it didn't happen on list, it didn't
happen." '' (yes, probably from someone that develops or sales a
mailing list software) Hehehe
No. That is official ASF policy summarized as a motto:
https://community.apache.org/ne
``There's a saying here that "if it didn't happen on list, it didn't
happen." '' (yes, probably from someone that develops or sales a
mailing list software) Hehehe
No. That is official ASF policy summarized as a motto:
https://community.apache.org/newbiefaq.html#NewbieFAQ-IsthereaCodeofCond
Hi Nathan,
``There's a saying here that "if it didn't happen on list, it didn't
happen." '' (yes, probably from someone that develops or sales a
mailing list software) Hehehe
I think we need to have a middle ground, if every single commit needs
to "happen on list, to be considered as happen", it
Sebastien,
If all the discussions that happens on github start to happen here,
this mailing list will be just like the nuttx-commits mailing list.
So, your point is a catch 22! (dilemma)... You are against using
github and against have a mailing list with huge email messages.
Also you cannot com
I do think that as a project community, this is an important discussion to have.
There are significant changes taking place regularly. I am in favor of
improving the code, improving our POSIX-like / Linux-like / Unix-like
compliance as much as is feasible while supporting deeply embedded and
small
I dont think your point of view is very realistic. You seem to be
turning the situation into something that pleases you but is not really
compatible with what can be observed from outside.
In the archive for 2023 there are 2035 topics, I just overlooked more
than 600 of them and ALL of them ar
s/he/here/
On 3/8/23, Alan C. Assis wrote:
> Hi Sebastien,
>
> Yes, that commit list is mostly for people who don't want to use
> github but still wanting to see what is going on.
>
> Sometimes when a very important PR raises some concern on GitHub PR,
> people post their concern he, it already h
Hi Sebastien,
Yes, that commit list is mostly for people who don't want to use
github but still wanting to see what is going on.
Sometimes when a very important PR raises some concern on GitHub PR,
people post their concern he, it already happened many times.
But again: the best way to guarantee
Hi,
I had a look and this mailing list is not made for human consumption.
No one has ever sent a message on it manually, right?
In practice, important changes are still NOT discussed on the DEV
mailing list.
You said yourself that "all development has moved to github".
As soon as automated
HI Sebastien,
It is already done, you just need to subscribe to
https://lists.apache.org/list.html?comm...@nuttx.apache.org to receive
all commits messages and discussions.
Everything is archived on apache side!
BR,
Alan
On 3/8/23, Sebastien Lorquet wrote:
> Apache projects are required to us
Many people are affected by this double echo
https://github.com/apache/nuttx/issues/8731
Sebastien
Le 07/03/2023 à 17:09, Gregory Nutt a écrit :
I imagine that this is occurring because readline also echos the input:
https://github.com/apache/nuttx-apps/blob/master/system/readline/readline_c
Apache projects are required to use mailing lists for long term archival
purposes.
It seems to me that this project is avoiding that rule and moved all
development to github
This is in contradiction with the Apache project rules.
I request clarification on this situation and requirement (in
62 matches
Mail list logo
