The lockcount is thread-specific data and should not require any locking since
it is only accessed by a single thread (not true of other SMP lock-related
data). This looks like a good clue, but I think does not address the heart of
the issue.
> > > If you prefer modlib, please reply with -1.
> > > If you recommend libelf, please reply with +1.
Rules for voting are a little different for code changes.
The required Apache voting process is here:
https://www.apache.org/foundation/voting.html
For code changes, that document says: "Vot
What if you need both versions at the same time? Rather than an option to use
one or the the other, options to enable one or both would be more flexible.
My issues in the past with "pretty printers" were most mostly with C
comments. Most pretty-printers just scramble comments, especially if
they don't understand the comment indentation. NuttX multi-line comments
are not supported by anything AFAIK. And comment information that has a
columnar or
Coding style change are discussed in INVIOLABLES.md:
https://github.com/apache/nuttx/blob/master/INVIOLABLES.md#clear-consistent-standardized-coding-style
From: Nathan Hartman
Sent: Wednesday, March 19, 2025 6:03 AM
To: dev@nuttx.apache.org
Subject: Re: [EXT] Re
&preview=/139629402/140774634/NxWM-ScreenShots.pdf
On 3/11/2025 5:38 PM, Gregory Nutt wrote:
Sounds like you need an nxterm. An nxterm is the logical counterpart
to an xterm. You can find it at nutts/grapphics/nxterm.
It supports echoing text in a framebuffer and quite a few VT100
keyb
Sounds like you need an nxterm. An nxterm is the logical counterpart to
an xterm. You can find it at nutts/grapphics/nxterm.
It supports echoing text in a framebuffer and quite a few VT100 keyboard
inputs. There are all also lots of example to illustrate building and
using it. It hasn't be
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
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
On 1/11/2025 9:20 PM, Tomek CEDRO wrote:
By the way is there a way so that PR from "wild mirrors" like on
GitLab or Forgejo could land into the GitHub?
You would have to push such commits to a branch on your local GH
account and then create a PR to the upstream?
This is way outside my areas
On 1/11/2025 6:00 PM, Tomek CEDRO wrote:
On Sat, Jan 11, 2025 at 11:02 PM Lee, Lup Yuen wrote:
What is Forgejo? Think GitHub… But Open-Source and Self-Hosted! Forgejo is a
Git Forge, the server code that will publicly host and share a Git Repo.
(Including our NuttX Repo)
In this article, w
> Exactly :-) There are more and more powerful chips out there with Cortex-A
> CPU or big RISC-V one day we may outperform big OS with NuttX on them :-)
Those "BIG OSes" perform a different function than an RTOS. The big OS is not
an RTOS and does not have real-time performance. Their default
I remember some discussion about a PR to support traditional out-of-tree
builds. Was that not merged?
On 12/17/2024 11:22 AM, Tomek CEDRO wrote:
On Tue, Dec 17, 2024 at 5:32 PM Matteo Golin wrote:
Yesterday my PR was merged to add preliminary support for the BCM2711 chip and
Raspberry Pi 4B board.
You can take a look here if you'd like to see the
changes:https://github.com/apache/nuttx/pull/15
On 12/10/2024 7:59 AM, Nathan Hartman wrote:
On Tue, Dec 10, 2024 at 8:11 AM spudaneco wrote:
I wonder if we should also disable the prioritization APIs. In the
normal, default case, any reprioritization of an IRQ introduces a fatal,
mysterious bug. That is because nested interrupts will occ
On 12/9/2024 3:52 PM, Nathan Hartman wrote:
Hi all,
Unfortunately I missed the PR before it was merged, but PR-15073 has
broken High Priority, Zero Latency Interrupts! Fortunately I caught it
now. It was merged 17 hours ago.
This PR removed a very important Kconfig: config ARMV7M_USEBASEPRI,
On 11/17/2024 6:09 AM, Simon Filgis wrote:
Dear all,
Everything still works.
There is one thing that I found interesting:
I have a ftp_server running. This server is not accepting long filenames
any more. I cannot remember this limitation from previviouse usage. Though
in the past I saw the fil
On 11/8/2024 1:41 AM, Takashi Yamamoto wrote:
have you decided that targets w/o 64-bit integers are not good enough
reason to diverge from what the latest posix says about time_t?
are we effectively dropping those targets?
Anything that has a GCC port should have int64_t. For other cases, it
On 11/7/2024 12:34 PM, Tomek CEDRO wrote:
Still it will be possible to set _by_hand_ other values (i.e. int32_t
or uint32_t) via kconfig when necessary for older / smaller platforms.
But not POSIX 2024 compliant. We have forbid non-compliant options in
the past. The option would basic say
On 11/7/2024 10:59 AM, Tomek CEDRO wrote:
Does adding kconfig's configurable time_t with uint32_t default
(as-is) with option to change int32_t and int64_t sounds good? Should
we use manual selection only or auto-detection (i.e. int64_t on 64-bit
archs)? :-)
/Initial Response /
Not re
On 11/7/2024 5:00 AM, michal.lyszc...@bofc.pl wrote:
Having code we know is going to crap out in the near future is kinda strange
design choice. I think you could have ignored it when there was 50 years left,
but this will happen in 14 years which is not that far for embedded systems
that can wor
On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:
my suggestion is to keep our time_t unsigned for now and revisit
when/if we solve the issues of targets w/o 64-bit integers.
(either by improving the toolchains, or stop supporting those targets,
or inventing a way to workaround the year 2038 issu
On 11/7/2024 12:57 AM, Takashi Yamamoto wrote:
my suggestion is to keep our time_t unsigned for now and revisit
when/if we solve the issues of targets w/o 64-bit integers.
(either by improving the toolchains, or stop supporting those targets,
or inventing a way to workaround the year 2038 issue
Here are solutions and details of implementations as implemented by
other OSs and file systems (the year 2038 problem does apply to
timestamps and meta-data in file systems too! Including NFS). See
https://en.wikipedia.org/wiki/Year_2038_problem
Implemented solutions
* Starting with R
On 11/5/2024 9:18 PM, Takashi Yamamoto wrote:
does that GCC have int64_t?
Yes, according to include/nuttx/compiler.h.
zNEO (z16) and z8 are no long supportable without ZDS-II. Other z80s
don't work with common small compilers like SDCC anymore.
i guess people who care these targets should
On 11/5/2024 8:35 PM, Byron Ellacott wrote:
Hi Takashi,
ideally, we should use int64_t for all targets unconditionally, IMO.
however, in practice, 64-bit integers don't seem available for some of
our targets. (ez80, z8, z16)
maybe someone can add 64-bit integer support to their toolchains. but
On 11/5/2024 6:57 AM, Ville Juven wrote:
For direct user level access, one option is to move tg_envp to TLS /
task_info_s. This way the user could access the memory without boring a hole
into the kernel.
The same environ is used by all threads in a task group/process. If one
thread changes t
On 11/5/2024 3:43 AM, Takashi Yamamoto wrote:
i guess it's possible to implement it similarly to what we do for errno.
eg.
# define environ (*get_environ_ptr_ptr())
although it still isn't quite posix compatible, it might be good
enough for many applications.
d18be28c82a2a6d82115c8af19d/shel
You are right, there is no requirement by any standard that time_t be
signed. Lots of discussion on Wikipedia:
https://en.wikipedia.org/wiki/Unix_time
The only motivation for making time_t signed is for compatibility with
GLIBC. For example, some very old Unix systems permit negative time
v
Samsung did add journaling support to SmartFs in their fork of NuttX:
https://github.com/Samsung/TizenRT/tree/master/os . The Samsung fork is
Apache 2.0
Porting that journaling support might be one lower effort way to improve
power safety with SmartFS (which already supports wear leveling an
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.
removed from the boards.
bt_uart.c should probably be removed.
Ya win some and ya lose some.
On 10/1/2024 7:47 AM, Gregory Nutt wrote:
The driver structure is contained in the struct file (filep->struct
file->inode->u.file_operations. The operation of many file systems,
drivers, etc.
The driver structure is contained in the struct file (filep->struct
file->inode->u.file_operations. The operation of many file systems,
drivers, etc. depend on the additional in these other structures.
The driver interface is given by file_operations. Notice that each
method requires an ins
On 9/30/2024 12:25 PM, michal.lyszc...@bofc.pl wrote:
On 2024-09-30 12:51:06, Matteo Golin wrote:
Hello,
I did find a function called `stm32_get_uart()` which returns the UART
device; this is more what I am looking for. It doesn't seem like most
other platforms implement a similar function thoug
On 9/30/2024 11:50 AM, Gregory Nutt wrote:
On 9/30/2024 10:51 AM, Matteo Golin wrote:
The best idea I can come up with is to have the RN2483 driver perform such an
`open()` call, so that the registration
function for the device takes the UART output's pathname as an input parameter
in
On 9/30/2024 10:51 AM, Matteo Golin wrote:
The best idea I can come up with is to have the RN2483 driver perform such an
`open()` call, so that the registration
function for the device takes the UART output's pathname as an input parameter
in place of the device struct
(`uart_dev_t`). But this
On 9/6/2024 5:46 AM, Nathan Hartman wrote:
On Fri, Sep 6, 2024 at 3:11 AM raiden00pl wrote:
I ported some of them a while back and other people ported more than I
did,
but I don't think there's a list of what was ported and what wasn't. If
someone could go through CWIKI and Documentation and
One more time... I meant to respond to the list.
On 9/5/2024 6:54 PM, Ritvik Tanksalkar wrote:
Hi Gregory,
Thanks alot for pointing me to the correct documentation, just what I
needed!.
Warm Regards,
Ritvik Tanksalkar
There is a lot of critical technical documentation in Confluence under
th
On 8/28/2024 7:15 PM, Daniel Appiagyei wrote:
Hi Gregory, thank you for the quick response!
RE: 'lockcount' needing to be in a critical section:
That's good information to know, I wasn't aware before. I'm searching nuttx
for exact matches of the string 'sched_lock();' to find occurrences and
s
On 8/28/2024 6:14 PM, Daniel Appiagyei wrote:
Hi all,
Looking at sched_lock.c (
https://github.com/apache/nuttx/blob/master/sched/sched/sched_lock.c#L187),
, specifically at the non-SMP sched_lock() implementation, how do we ensure
that:
1. There's no data-race when incrementing the lock count:
On 8/28/2024 9:43 AM, raiden00pl wrote:
I don't know what was the initial intention about `drivers/`, only Greg can
answer this question.
All directories except for arch/ and board/ should have only generic
code that can be built with all all compilers and for any target. That
is true for almos
Most SMP discussions are pre-Apache. Try old Google group:
https://groups.google.com/g/nuttx/search?q=smp
Maybe even the archived Yahoo group: https://nuttx.yahoogroups.narkive.com/
Or maybe the old pre-Apache Wiki
https://cwiki.apache.org/confluence/display/NUTTX/SMP
https://cwiki.apache.org
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.
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
On 8/2/2024 12:06 PM, Ritvik Tanksalkar wrote:
Hello,
I'm working on a project where I need to compile the NuttX kernel to use
the system's standard library (stdlib) instead of its custom
implementation. My goal is to have NuttX use the host system's stdlib
functions rather than the ones provide
On 7/21/2024 5:47 PM, Gregory Nutt wrote:
On 7/21/2024 5:38 PM, Nathan Hartman wrote:
Hi Alan,
I think we should have "int main(int argc, const char * argv[])" (added
'const' for argv). Maybe should grep for all instances of main in
our code
and docs and add cons
On 7/21/2024 5:47 PM, Gregory Nutt wrote:
On 7/21/2024 5:38 PM, Nathan Hartman wrote:
Hi Alan,
I think we should have "int main(int argc, const char * argv[])" (added
'const' for argv). Maybe should grep for all instances of main in our
code
and docs and add const? I&
On 7/21/2024 5:38 PM, Nathan Hartman wrote:
Hi Alan,
I think we should have "int main(int argc, const char * argv[])" (added
'const' for argv). Maybe should grep for all instances of main in our code
and docs and add const? I'm willing to do that.
Let me know,
Nathan
POSIX specifies the req
The prototypes of standard interface functions are specified in the
POSIX standard. It would be a POSIX violation to use whatever prototype
you happen to like most. No one gets to "improve" POSIX.
read() is specified here
https://pubs.opengroup.org/onlinepubs/9699919799/functions/read.html
On 7/9/2024 9:10 AM, michal.lyszc...@bofc.pl wrote:
I am just copy pasting my message from other thread, as I did not see
that one in time :) So my proposition is:
I think I would be good if nuttx had something like /sbin/init that would
do some very simple service management. Then you could jus
On 7/7/2024 6:05 AM, Alan C. Assis wrote:
I was thinking about an idea to include some #ifdefs to detect that some
probable feature combination:
https://github.com/apache/nuttx/pull/12638
I.E.: if the user selected NET and IPv4 it is probable that he will need
ICMP, but we cannot enforce th
On 7/4/2024 4:44 PM, Alan C. Assis wrote:
I think Greg avoided using submodules because there are many issues caused
by it.
In fact submodules could avoid this issue, but maybe we could have some
marks indicating the last commit expected on apps/ to the current nuttx/
This way if someone git
On 6/27/2024 9:30 AM, Tomek CEDRO wrote:
Hey there Alan :-)
+1 here :-)
I would put that to apache/nuttx-deps repo so maintenance is easier
and more coherent with the rest of the project :-)
Have a good day folks :-)
Tomek
Many of have licenses that are incompatible with Apache 2 and so coul
On 6/21/2024 9:14 AM, Xiang Xiao wrote:
but, different devices expose to the different subsets of API. e.g. some
devices mayn't enable the net subsystem at all, any application which
calls socket api will fail to load.
Right, that is a consequence of size reduction using a minimal,
incomplete
On 6/21/2024 3:55 AM, Xiang Xiao wrote:
but there is no stable ABI on NuttX, so you can't copy elf from one type of
device to another.
Wouldn't that work if (1) the ELF module is partially linked so that it
relies a symbol table and dynamic linking at run time so that there is
no a priori knowl
On 6/13/2024 8:32 PM, Gregory Nutt wrote:
On 6/13/2024 11:56 AM, Gregory Nutt wrote:
Changing the existing driver interface would break the NX graphics.
NX graphics is mis-named. It is not a graphics system like LVGL, but
a windowing system like X. Whatever you do should not break the
On 6/13/2024 11:56 AM, Gregory Nutt wrote:
Changing the existing driver interface would break the NX graphics. NX
graphics is mis-named. It is not a graphics system like LVGL, but a
windowing system like X. Whatever you do should not break the
windowing system and, in fact, really should
On 6/13/2024 11:15 AM, Tim Hardisty wrote:
I am getting in a mental pickle regarding LVGL (V9) and NuttX, in
conjunction with the SAMA5D2 with it's built in LCD Controller
peripheral.
In the past - bare metal - I have simply set up two buffers so one can
be written to while the other is copie
On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch,
On 5/26/2024 8:10 PM, Stuart Ianna wrote:
Some of the integration at this level is going to be tricky, as Litex
customisations may not be risc-v generic.
The only guideline with this is that all RISC-V-and-Litex-specificlogic
needs to be constrained to reside in arch/risc-v/src or
boards/ris
Adding non-standard APIs would be not be a good decision for the
future of a standards compliant OS.
Sorry to respond again. Perhaps I am not understanding properly. Are
you proposing another set of APIs or instead proposing to replace the
standard APIs with a different implementation.
On 5/26/2024 5:03 PM, Stuart Ianna wrote:
With the riscv/litex port, we're able to access the TIME and TIMEH CSRs in
usermode. I would like to take advantage of this feature to replace the
proxies for syscalls, such as timer_gettime with an equivalent
implementation that avoids a context switch
There is some brief information about dhara here:
https://github.com/dlbeer/dhara . It is an FTL that provides many of the
features described previously:
* Wear leveling,
* Hardware/software EEC
It does not appear to do
* Bad block detection
* Marking of bad blocks
The nicest thing is th
Seems like dhara.c was integrated into mainline, but they didn't submit
support to YAFFS (if I remember correctly it was because YAFFS requires
license payment for commercial usage).
There no references to either under fs/.
The YAFFS website is not responding. This is what I get about licensin
> Mr. Greg Nutt implemented it for Atmel about 10 years ago, but if I
> remember correctly, he never got it well tested because there is no
FS for
> NAND on NuttX.
I did test the FS's that were available and they mostly worked on these
platforms. I could actually run nxffs and smartfs for a l
On 5/9/2024 11:02 PM, Mark Stevens wrote:
Hmmm... the UART device will closed when the kernel thread is killed, right?
When the device is closed, it is also flushed I believe. If those two things
are true, then data loss would be expected, right?
Yes, the UART is closed just before we perfo
On 5/9/2024 10:23 PM, Mark Stevens wrote:
The issue arises if I try to kill the kernel thread reading from the UART and
then try to start a user thread reading from the same UART.
Hmmm... the UART device will closed when the kernel thread is killed,
right? When the device is closed, it is
This problem is reported for a lot a platforms and seems to be a
hardware issue, usually associated with FIFOs and buffers.
If you rule everything else out, then you can also consider some of the
more unusual causes. On some hardware, small differences in BAUD can
result in the kind of data l
On 5/4/2024 7:57 AM, Kenneth Pettit wrote:
On the Tiny Tapeout discord channel, the engineer who submitted the
Z80 design said the z88dk toolchain was the "most mature". Looking at
it I believe he may be correct as it has a full compliment of tools
simialr to an GNU toolchain. It uses sdcc but
On 5/3/2024 8:31 AM, Kenneth Pettit wrote:
There is an effort to make a Z80 replacement chip:
https://app.tinytapeout.com/projects/668
This is just a start since there are limited I/O pins on Tiny Tapeout,
but I think the plan might be to eventually put it on an MPW to have a
fully functiona
On 5/3/2024 2:12 AM, Lee, Lup Yuen wrote:
https://lupyuen.github.io/articles/pr#check-coding-style
Nice article. This would be good to have in the documentation.
I'm not aware of a script that does auto-formatting for NuttX Code. I do it
manually in VSCode :-)
There used to be a couple of sc
'nsh: i2c: command not found' means that the i2c app was not built into the
image and/or was not registered at build time. NSH is simply complaining that
you are trying to run an app that does not exist.
Did you remember to include logic in your board/src file in order to initialize
and regis
On 4/14/2024 7:02 AM, Ahmad Noori wrote:
Hi
I have a custom board with stm32h743vit6
I port nuttx to this board and i am using it.
I have problem with mmcsd sdio and i cant mount sd card. I get error 19
when mount sd card.
I test my hardware with stm32cubeide and its ok.
Please help me to solv
On 3/28/2024 9:21 PM, yfliu2008 wrote:
> I am still trying to understand existing userland address envrionment
in NuttX kernel mode, I saw the following regions defined in
"arch/Kconfig": config ARCH_TEXT_VBASE, config ARCH_DATA_VBASE, config
ARCH_HEAP_VBASE, config ARCH_SHM_VBASE, config AR
On 3/28/2024 8:23 PM, Gregory Nutt wrote:
...
On all platforms that I am aware of, the virtual address of the
framebuffer is just a configurable constant. This makes sense if the
framebuffer is in a fixed virtual address in every process. The kernel
can manage the virtual address space
On 3/28/2024 7:05 PM, yfliu2008 wrote:
Yes the user land only use standard file operations like
"mmap()/read()/write()/munmap()/ioctl()" etc to access the device memory and interruption
status via the exposed device files like "/dev/uio3" etc.
Sorry it took me so long to catch on.
My origi
dard POSIX mmap() to accomplish the mapping.
On 3/28/2024 3:01 PM, Gregory Nutt wrote:
I found this document which describes the use cases for UIO in Linux:
https://www.kernel.org/doc/html/v4.13/driver-api/uio-howto.html . They
use mmap() to addess device memory: "|/dev/uioX| is use
3/28/2024 12:25 PM, Gregory Nutt wrote:
A more interesting task would be to port NxLib to run on top of the
existing NuttX NX Windows System:
* https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
* https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsy
A more interesting task would be to port NxLib to run on top of the
existing NuttX NX Windows System:
* https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=139629474
* https://cwiki.apache.org/confluence/display/NUTTX/NX+Graphics+Subsystem
That would not be particularly easier, h
On 3/28/2024 11:17 AM, Shijo George wrote:
I was planning to port NanoX to NuttX as part of GSoC. Is anyone familiar
with NanoX? Any suggestions and help would be much appreciated.
Regards ,
Shijo george
This will likely be a very difficult job. Nano-X is a complete X-11
replacement from the
On 3/28/2024 1:03 AM, yfliu2008 wrote:
...
Have "up_addrenv_map(), up_addrenv_unmap()" alike interfaces added to
encapsulate MMU mapping operations of different chip architectures. These are used by UIO
component to a.
As an architectural description it is confusing to understand what you
se
On 3/28/2024 8:21 AM, Gregory Nutt wrote:
On 3/28/2024 1:03 AM, yfliu2008 wrote:
Have UIO framework added which exposes an "uio_register_device()"
interface to BSP so that to instantiate different UIO devices
with specific device path, address range and IRQ data.
Then userland ap
On 3/28/2024 1:03 AM, yfliu2008 wrote:
Dear experts,
I am wondering if we can have an Userspace IO alike component added to NuttX
kernel? It can help exposing video frame buffers or neural network
accelerators alike devices to user land services. Often kernel has little to do
with such devic
ory
(only) would be the more practical way to accomplished what you want to do.
On 3/21/2024 4:43 PM, Gregory Nutt wrote:
I think we need to continue to use PRs at some point in the process.
PRs are so tied into our CI that I don't think we could work around it.
Can you use another GIT rep
I think we need to continue to use PRs at some point in the process.
PRs are so tied into our CI that I don't think we could work around it.
Can you use another GIT repository? If you create a PR on gitlab or
bitbucket, someone could move the PR to github. Or perhaps we could
take commits f
On 3/15/2024 11:10 PM, Saurav Pal wrote:
All in all, I am *against* Rust being introduced in the kernel. However, I
am fine with the language being in the very leaf nodes. Like some drivers,
userspace applications, or userspace filesystems (FUSE)... especially those
that only interact with the ke
nity support" because it means
something like "unanimity" and as a guy called Nelson Rodrigues once said:
"All unanimity is dumb".
Although (fortunately) we don't have full community support, it seems we
have a direction: only application support for now.
Best Regards,
On 3/13/2024 4:11 PM, Alan C. Assis wrote:
I think we are having a CMakefile deja-vu here, don't we? (I hope we don't
lose any developer this time)
Let's make sure that we have full concurrence from the community. Our
responsibility is to serve the whole community and not just the special
On 3/13/2024 2:42 PM, Tomek CEDRO wrote:
You want Rust in the core go ahead write RustOS have fun maintaining it for 5
years and show us its better :-)
You are probably right in that. It would probably be necessary have to
be a different OS if any extensive amount of Rust is used. POSIX
d
There is some discussion in Issue #11907 proposing to use the Rust
language within the OS (vs Rust applications on a pure C OS). If anyone
has any feelings, Pro or Con, you should participate in this
discussion. This kind of decision impacts the entire community and
should have the input of
On 3/12/2024 5:12 AM, Nathan Hartman wrote:
Try Alan's suggestion to use stack monitor, and that will help understand
if there is something wrong. (If it shows that old stack size was OK, while
we know corruption was happening, then we will know to look for some out of
bound write.)
Does the stac
After enlarging the stack size of "AppBringUp" thread, the remote node can boot NSH
on RPMSGFS now. I am sorry for not trying this earlier. I was browsing the "rpmsgfs.c"
blindly and noticed a few auto variables defined in the stack... then I thought it might worth a try so
I did it.
That is
On 3/12/2024 1:10 AM, yfliu2008 wrote:
On the other hand, if we choose not mounting NSH from the RPMSGFS, it can boot
smoothly and after boot we can manually mount the RPMSGFS for playing.
That sounds like an initialization sequencing problem. Perhaps
something is getting used before it has be
:20 PM, Simon Filgis wrote:
Is there a way to colorize heap to track down the bandid? Like CRC pattern
on all the spaces around and check on every call that the CRC pattern ist
still OK?
Gregory Nutt schrieb am Mo., 11. März 2024, 19:27:
If the memory location that is corrupted is consistent
00 AM Gregory Nutt wrote:
The reason that the error is confusing is because the error probably did
not occur at the time of the assertion; it probably occurred much earlier.
In most crashes due to heap corruption there are two players: the
culprit and the victim threads. The culprit thread act
kasan.c:117 task: Idle_Task
process: Kernel 0x70023c0
The call stack looks like:
#0 _assert (filename=0x7060f78 "kasan/kasan.c", linenum=117, msg=0x7060ff0 "panic", regs=0x7082720
Original
On 3/10/2024 4:38 AM, yfliu2008 wrote:
Dear experts,
When doing regression check on K230 with a previously working Kernel mode
configuration, I got assertion error like below:
#0 _assert (filename=0x704c598 "mm_heap/mm_malloc.c", linenum=245, msg=0x0,regs=0x7082730
This does indicate
On 2/24/2024 11:42 AM, Gregory Nutt wrote:
On 2/24/2024 11:39 AM, Jernej Turnsek wrote:
@Tomek No, my SD card filesystem is notu mounted read-only, because I
can
delete single files. I believe that rm * is just not implemented.
There is no logic in NSH that expands "*" to a list of
On 2/24/2024 11:39 AM, Jernej Turnsek wrote:
@Tomek No, my SD card filesystem is notu mounted read-only, because I can
delete single files. I believe that rm * is just not implemented.
There is no logic in NSH that expands "*" to a list of all files in the
current directory. It is passed on to
1 - 100 of 1038 matches
Mail list logo
