On Mon, May 25, 2020 at 3:41 PM Xiang Xiao wrote:
>
>
>
> > -Original Message-
> > From: Nathan Hartman
> > Sent: Monday, May 25, 2020 12:00 AM
> > To: dev@nuttx.apache.org
> > Subject: Re: mbedtls
> >
> > On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
> > wrote:
> > > Some mont
> -Original Message-
> From: Nathan Hartman
> Sent: Monday, May 25, 2020 12:00 AM
> To: dev@nuttx.apache.org
> Subject: Re: mbedtls
>
> On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
> wrote:
> > Some months ago I suggested that NuttX could focus only in the kernel
> > and we
>From nuttx/include/nuttx/mm/mm.h, MM_KERNEL_USRHEAP_INIT should always be
>defined for CONFIG_BUILD_FLAT:
/* Terminology:
*
* - Flat Build: In the flat build (CONFIG_BUILD_FLAT=y), there is only a
* single heap access with the standard allocations (malloc/free). This
* heap is referred t
So I was left without heap at boot, and crashing (also stacks of course, but
that was not what I meant to say).
Hi,
Right now, looking at the file nx_start.c, all calls to up_allocate_heap are
being done when one of these flags are defined:
#if defined(MM_KERNEL_USRHEAP_INIT) || defined(CONF
Hi,
Right now, looking at the file nx_start.c, all calls to up_allocate_heap are
being done when one of these flags are defined:
#if defined(MM_KERNEL_USRHEAP_INIT) || defined(CONFIG_MM_KERNEL_HEAP) || \
defined(CONFIG_MM_PGALLOC)
I was just left without stack when re-basing to the latest
On Mon, May 25, 2020 at 1:00 AM Nathan Hartman wrote:
>
> On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
> wrote:
> > Some months ago I suggested that NuttX could focus only in the kernel
> > and we could create an external distribution using some build system
> > like buildroot, yocto, e
On Sun, May 24, 2020 at 7:58 AM Alan Carvalho de Assis
wrote:
> Some months ago I suggested that NuttX could focus only in the kernel
> and we could create an external distribution using some build system
> like buildroot, yocto, etc. But as some people pointed, maybe a great
> strength of NuttX i
I think we should continue to wait a while and continue doing
community building. Meanwhile, one of the following might happen:
* Either someone joins and fixes/maintains the Windows build, or
* Windows support for *nix compatibility will become much more
extensive over time
I have a feeling
On Sun, May 24, 2020 at 11:35 AM Gregory Nutt wrote:
> Some time back we actually voted to keep the Windows native build in
> place, even though it is not fully functional or ready for prime time.
> We did mark it as EXPERIMENTAL. The idea is that some champion for this
> build would emerge and p
I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56:
"build: Don't need use $(DELIM) in include statement"
This changes various lines in Make.defs from this:
include wireless$(DELIM)spirit$(DELIM)drivers$(DELIM)Make.defs
to this:
include wireless/spirit/lib/Make.defs
On Sun, May 24, 2020 at 11:27 AM Gregory Nutt wrote:
> > I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56:
> > "build: Don't need use $(DELIM) in include statement"
> >
> > This changes various lines in Make.defs from this:
> > include wireless$(DELIM)spirit$(DELIM)drivers$(
I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56:
"build: Don't need use $(DELIM) in include statement"
This changes various lines in Make.defs from this:
include wireless$(DELIM)spirit$(DELIM)drivers$(DELIM)Make.defs
to this:
include wireless/spirit/lib/Make.defs
I'm confused about commit edb0ce2d5afa8a0905bd4536ac39eaf1819dfc56:
"build: Don't need use $(DELIM) in include statement"
This changes various lines in Make.defs from this:
include wireless$(DELIM)spirit$(DELIM)drivers$(DELIM)Make.defs
to this:
include wireless/spirit/lib/Make.defs
Don't
I’m concerned that you are discussion doing work outside of the Apache
repositories. Why is the main issue here?
I think Alan summarized this well. We are already doing work outside of
the Apache repositories here:
https://bitbucket.org/nuttx/?repo_name=apps-old . We have discussed
this
Hi Justin,
The point we are discussing is how to integrate external/third-party
projects on NuttX apps repository. The licensing it only one of many
issues we have.
Some months ago I suggested that NuttX could focus only in the kernel
and we could create an external distribution using some build
Should be fixed by:
https://github.com/apache/incubator-nuttx/pull/
To catch the similar issue in the future, add b-g474e-dpow1 to the test list:
https://github.com/apache/incubator-nuttx-testing/pull/45
Thanks
Xiang
> -Original Message-
> From: Apache Jenkins Server
> Sent: Sunday, M
16 matches
Mail list logo
