On Mon, May 18, 2020 at 12:12 PM Gregory Nutt wrote:
> I think we need to assure that these two "tiers" are compatible and use
> the same test infrastructure. The should have these things in common:
I'd like to move this discussion to a new thread, titled "Automated
Testing" without several leve
* The next tier could be an automated test suite that runs in a
simulator.
This would be accessible to the greatest numbers of developers and
contributors, because there's nothing to buy.
* The highest tier could be testing on a reference hardware board.
I think we need to assure th
So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across
On Mon, May 18, 2020 at 12:03 AM Gregory Nutt wrote:
> Build testing is important but does not address functionality. Things
> can be completely broken and still build perfectly.
Correct.
> Currently our functional testing strategy is simply to ask people to
> check releases. But no problems ha
>
>
> That is true. The assumption is that the stack size of the built-in
> application will be big enough for the replacement ELF application.
> That might not be true. But in the case of replacing a built-in
> application with an ELF application, the rule is that we cannot
> modify
> the
So, in current git HEAD [1], what is the search order now?
Is it back to:
- Elf
- Built-in
- NSH
Or is it:
- Built-in
- Elf
- NSH
It is not so clean and well partitioned. It is more like:
o IF Built-in available
- Elf
- IF NOT Elf
Built-in
o Elf
o NSH
The logic is spread across a
On Mon, May 18, 2020 at 10:38 AM Gregory Nutt wrote:
> >> Yes, the best solution is to extend ELF with stack and priority info.
> >> But before that happen, gathering this info from the built-in app
> >> table is workable alternative:
> >> 1.Keep the trying order(file system, built-in and nsh comm
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file s
Yes, the best solution is to extend ELF with stack and priority info.
But before that happen, gathering this info from the built-in app
table is workable alternative:
1.Keep the trying order(file system, built-in and nsh command)
2.And get the stack/priority from built-in app table for file sys
On Mon, May 18, 2020 at 9:07 PM Gregory Nutt wrote:
>
>
> > OK, by now I'll keep using the alternative to use another name for the
> > elf app/FILE_APPS, as seemingly intended by
> > chao.an in his commit.
> No, that was an error. The requirements have always supported
> replacement of built-in a
OK, by now I'll keep using the alternative to use another name for the
elf app/FILE_APPS, as seemingly intended by
chao.an in his commit.
No, that was an error. The requirements have always supported
replacement of built-in applications with ELF applications. That is a
recommended way for u
2300 28.1% /system/bin/nsh
> 3 2 100 FIFO Task--- Waiting Signal
> 020464 019528 95.4%! hello
>
> It is make sense to use the builtin attribute for applications if we
> enabled the BUILTIN_APPS / FILE_APPS at the same time.
>
> BRs,
> __
发件人: Gregory Nutt
发送时间: 2020年5月18日 6:59
收件人: dev@nuttx.apache.org
主题: [External Mail]Re: heap malloc when executing binary/elf file
Hi, Brennan,
>>> I just created incubator-nuttx-apps PR 255 that should restore the
>>> correct behavior:
>
I have no preference. At some point, I think we also have to say that
9.0.x "is what it is". Or do you see us continuing to maintain the
release forever? In the dark, pre-Apache past, I had about a two week
period after the release after which it "is what it is". I distrubuted
patches up un
On Sun, May 17, 2020 at 7:11 PM Brennan Ashton
wrote:
> On Sun, May 17, 2020, 3:59 PM Gregory Nutt wrote:
>
> > Hi, Brennan,
> > >>> I just created incubator-nuttx-apps PR 255 that should restore the
> > >>> correct behavior:
> > >> https://github.com/apache/incubator-nuttx-apps/pull/255
> > >>
On Sun, May 17, 2020, 3:59 PM Gregory Nutt wrote:
> Hi, Brennan,
> >>> I just created incubator-nuttx-apps PR 255 that should restore the
> >>> correct behavior:
> >> https://github.com/apache/incubator-nuttx-apps/pull/255
> >>
> >> This is a major bug and, if we release do a bugfix release somet
Hi, Brennan,
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior:
https://github.com/apache/incubator-nuttx-apps/pull/255
This is a major bug and, if we release do a bugfix release sometime,
this should be included.
I was thinking the same. I created a label ba
On Sun, May 17, 2020, 3:50 PM Gregory Nutt wrote:
>
> > I just created incubator-nuttx-apps PR 255 that should restore the
> > correct behavior:
> https://github.com/apache/incubator-nuttx-apps/pull/255
>
> This is a major bug and, if we release do a bugfix release sometime,
> this should be incl
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior: https://github.com/apache/incubator-nuttx-apps/pull/255
This is a major bug and, if we release do a bugfix release sometime,
this should be included.
I just created incubator-nuttx-apps PR 255 that should restore the
correct behavior: https://github.com/apache/incubator-nuttx-apps/pull/255
On 5/17/2020 3:33 PM, Gregory Nutt wrote:
Mystery solved.
It does not even try to load the elf file from file-system, it
directly
goes to the built-in ap
Mystery solved.
It does not even try to load the elf file from file-system, it
directly
goes to the built-in app.
That means that it failed to load the app on the file system. It
should
check in this order"
- Load file from file system if possible
- If not, run built-in application if possibl
Hi Greg and Alan,
> > It does not even try to load the elf file from file-system, it
> > directly
> > goes to the built-in app.
> That means that it failed to load the app on the file system. It
> should
> check in this order"
>
> - Load file from file system if possible
>
> - If not, run bu
However, got a new problem now which I've not figured out yet:
The binary loader does not load the elf if the program is a built-in
app... very strange..
It does not even try to load the elf file from file-system, it directly
goes to the built-in app.
That means that it failed to load the app
Hi Florian,
Does this problem only occur in version 9.0.0?
Or is it happening to the current master as well?
Are you following this tutorial: https://www.youtube.com/watch?v=oL6KAgkTb8M
Also you can increase the debug level (include warn and info).
BR,
Alan
On 5/16/20, Florian Wehmeyer wrote
Hi Alan,
updated it again to 9.0.0 and also good!
However, got a new problem now which I've not figured out yet:
The binary loader does not load the elf if the program is a built-in
app... very strange..
It does not even try to load the elf file from file-system, it directly
goes to the built-in
Hi Florian,
Nice to know you got if fixed.
It should be nice if you can test it again using the nuttx-9.0.0 release.
BR,
Alan
On 5/16/20, Florian Wehmeyer wrote:
> Hi all,
> just to let you know, the heap problem was solved after pulling the
> latest commit from master..
> Now I can use very
Hi all,
just to let you know, the heap problem was solved after pulling the
latest commit from master..
Now I can use very much of it, also I was able to use a lot more
features in the config, as cmd line history etc...
So, the available memory of 256K was not the problem, @Greg.
@Nathan: now ma
OK Greg,
could be that I was using too much.. using 64KB of ramdisk also.. I
disabled some of the comfortable features like cmd line history etc,
and was already able to alloc quite a bit more than before..
Will further improve the sram usage..
Also, I missed the commit
mm/mm_heap: fix mm_heap no
On Mon, May 11, 2020 at 5:01 PM Gregory Nutt wrote:
> That part has 256Kb of SRAM. That is more that many, but it could be
> that you are using too much SRAM and just cannot run ELF reliably. It
> does want a lot of SRAM.
If there isn't enough memory, I wonder why malloc doesn't return NULL?
Ha
No custom board, it's the tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.
That pa
No custom board, it's the tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use the CONFIG_ELF stuff.
That par
Thanks Nathan,
I'll check on that..
No custom board, it's the tm4c1294-launchpad.
Seems no general problem with heap allocation, so I guess it's not in
the linker script, it's rather directly linked to the usage of the elf-
binary loader, and there are only two configs in the nuttx repo which
use
On Mon, May 11, 2020 at 2:05 PM Florian Wehmeyer wrote:
> OK I already saw that simply increasing the heap is no solution,
> because it's already maximum size:
> mm_initialize: Heap: start=0x20008924
> size=227036
> mm_addregion: Region 1: base=0x20008924 size=227024
Tricky problem.
Is this for
OK I already saw that simply increasing the heap is no solution,
because it's already maximum size:
mm_initialize: Heap: start=0x20008924
size=227036
mm_addregion: Region 1: base=0x20008924 size=227024
--
Florian Wehmeyer
TFW Tech-Solutions
On Seg, 2020-05-11 at 14
looking more into the memory allocation debug, there is a lot more
dynamic allocation (obviously) when loading the elf program than
when loading the same program as built-in..
So, seems the problem is due to a high heap fragmentation, what
explains that a call to dmesg can also make the system cra
Hi all,
again a question related to the execution of external / elf programs:
When I use malloc within the running elf program, allocating more than
1K bytes, malloc seems to work (doesn't return NULL), but when I use
that memory (memset) I get a assertion/Kernel panic..
Funnily this does not
36 matches
Mail list logo
