See, I was thinking that it should be treated like all other functions
with no indention of the first pair of curly brackets. I didn't look for
other multi-line macro functions to compare with though. I'll go with
whatever is consistent with existing code in the repo.
- John
On 3/25/20 4:29
I also took a look at the coding standard guide to make sure I was in
compliance, but I'm unsure of where I should put the 'do'
#define mpu_priv_stronglyordered(base, size) do \
{ \
/* The configure the region */ \
== OR ==
#define mpu_user_flash(base, size) \
do { \
/* The configure th
I moved forward with converting inline functions to macros and thought I
would share a little before moving on. Things I did
1. Per Greg's suggestion, I added #ifdef CONFIG_ARM_MPU to mpu.h and
_mpuinit.h
2. Moved static inline functions mpu_control and mpu_configure_region
to up_mpu.c. I
Converting them to macros certainly reduces the amount of code that
needs to change.
Thanks for the link Nathan, I will take a look at that.
John
On 3/25/20 11:45 AM, Nathan Hartman wrote:
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
wr
On Wed, Mar 25, 2020 at 11:38 AM Xiang Xiao
wrote:
> On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
> wrote:
> >
> >
> > >> 1. For each chip, files that include mpu support need to add a
> > >> conditional to two included files
> > >>
> > >> #ifdef CONFIG_ARM_MPU
> > >> # include "mpu.h"
> > >>
On Wed, Mar 25, 2020 at 11:33 PM John Rippetoe
wrote:
>
>
> >> 1. For each chip, files that include mpu support need to add a
> >> conditional to two included files
> >>
> >> #ifdef CONFIG_ARM_MPU
> >> # include "mpu.h"
> >> # include "_mpuinit.h"
> >> #endif
> >
> > Wouldn't it make more sense
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of
mpu.h and _mpuinit.h. That way, the problem is fixed i
1. For each chip, files that include mpu support need to add a
conditional to two included files
#ifdef CONFIG_ARM_MPU
# include "mpu.h"
# include "_mpuinit.h"
#endif
Wouldn't it make more sense to put #ifdef CONFIG_ARM_MPU inside of mpu.h
and _mpuinit.h. That way, the problem is fixed i
Does anyone have any thoughts on this? I can start implementing the changes and
set up a PR.
John Rippetoe
Software Engineer
Robotic Research, LLC
(240) 631-0008
- Original Message -
From: "John Rippetoe"
To: "dev"
Sent: Monday, March 23, 2020 6:17:05 PM
Subject: R
On 3/20/20 5:40 PM, David Sidrane wrote:
the error will crop back up if MPU support is enabled without also
performing a protected build since up_mpu.c is only included in a
protected build.
Just a heads up there are some case on some HW (imxrt, maybe the K66 for the
DMA) were the MPU is neede
> Another example, we use MPU to protect the code section for NOXIP casein the
> flat mode.Some have used the MPU to catch runtime NULL pointer accesses.
> There is a HowTo for this case in the Wiki.Sent from Samsung tablet.
null
On Sat, Mar 21, 2020 at 5:15 AM John Rippetoe
wrote:
>
>
> >
> > You can try removing the static from the inline function definitions
> > in the header file. The code should then compile, however, you could
> > also get multiply defined functions at link time... Or maybe the
> > linker is smart e
CMN_CSRCS += up_mpu.c
> endif
> CHIP_CSRCS += imxrt_mpuinit.c
> ifeq ($(CONFIG_BUILD_PROTECTED),y)
> CHIP_CSRCS += imxrt_userspace.c
> endif
> endif
>
> -Original Message-
> From: John Rippetoe [mailto:jrippe...@roboticresearch.com]
> Sent: Friday, March 2
to:jrippe...@roboticresearch.com]
Sent: Friday, March 20, 2020 2:09 PM
To: dev@nuttx.apache.org
Subject: Re: Build errors with inline functions
I think at a minimum, we need to conditionally include mpu.h only when
the MPU support is actually needed. Options for that are CONFIG_ARM_MPU,
CONFIG_ARCH_US
You can try removing the static from the inline function definitions
in the header file. The code should then compile, however, you could
also get multiply defined functions at link time... Or maybe the
linker is smart enough to allow multiples???
Putting inline functions in header files
I think at a minimum, we need to conditionally include mpu.h only when
the MPU support is actually needed. Options for that are CONFIG_ARM_MPU,
CONFIG_ARCH_USE_MPU, or CONFIG_BUILD_PROTECTED. If we use either of the
first two, the error will crop back up if MPU support is enabled without
also p
If we want to support the compiler which don't support inline, it's better that:
1.Remove CONFIG_HAVE_INLINE from include/nuttx/compiler.h
2.Convert inline fucntion to macro to normal function
It isn't hard to fix because grep just can find inline about 100 times.
There are inline functions in
On Fri, Mar 20, 2020 at 11:07 PM Gregory Nutt wrote:
>
>
> > In C, if placing a function in a header, "static inline" is needed to avoid
> > a "multiple definitions" problem, but means that if the compiler decides
> > *not* to inline the function, and if the function is used from multiple C
> > mo
In C, if placing a function in a header, "static inline" is needed to avoid
a "multiple definitions" problem, but means that if the compiler decides
*not* to inline the function, and if the function is used from multiple C
modules, then some code bloat results because you could end up with
mult
On Thu, Mar 19, 2020 at 6:38 PM Gregory Nutt wrote:
>
> > More likely is the fact that inlining is disabled at -O0 and now the
> > functions really are implemented as static functions and generate
> > static functions. Now you really do have unreferenced static
> > functions. Try removing the s
On Fri, Mar 20, 2020 at 6:21 AM Gregory Nutt wrote:
>
>
> >> -O--> works
> >> -O2 --> works
> >> -O3 --> works
> >> -O0 --> fails
> >> -Os --> works
> > Because it builds when optimization is on, and because the error you
> > posted in your original post is a linker error, that leads me to
More likely is the fact that inlining is disabled at -O0 and now the
functions really are implemented as static functions and generate
static functions. Now you really do have unreferenced static
functions. Try removing the static storage class from the inline
prototypes.
What would wor
More likely is the fact that inlining is disabled at -O0 and now the
functions really are implemented as static functions and generate
static functions. Now you really do have unreferenced static
functions. Try removing the static storage class from the inline
prototypes.
Or try the alwa
-O--> works
-O2 --> works
-O3 --> works
-O0 --> fails
-Os --> works
Because it builds when optimization is on, and because the error you
posted in your original post is a linker error, that leads me to the
following hypothesis:
I think that with optimization turned on, there is some a
On Thu, Mar 19, 2020 at 6:01 PM John Rippetoe
wrote:
> That's interesting. Maybe there is a difference in the default flags between
> my compiler and what you and the build server are using. It looks like the
> default standard for my compiler is gnu90. I haven't done an exhaustive test
> on al
I just found that the nucleo-h743xi:pwm config did not fail, so I dug into that and found that
compiler optimizations play a role in whether the build completes. With the "No
Optimization" setting selected, the build fails. Turning on "Full Optimization"
allows the build to complete. I also
While we probably should get to the root of the flags and specify them more
completely if needed, I would highly recommend using the gcc compiler built
by ARM.
https://developer.arm.com/tools-and-software/open-source-software/developer-tools/gnu-toolchain/gnu-rm
It is kept quite up-to-date and te
code to compile, should we not specify the minimum standard
necessary in the Make.defs?
Thanks for the help. Sorry this got a little long winded.
- John
- Original Message -
From: "Abdelatif Guettouche"
To: "dev"
Sent: Thursday, March 19, 2020 2:29:30 PM
Subje
OPDIR)/binfmt/libnxflat/gnu-nxflat-pcrel.ld -no-check-sections
> LDNXFLATFLAGS = -e main -s 2048
>
> ASMEXT = .S
> OBJEXT = .o
> LIBEXT = .a
> EXEEXT =
>
> ifneq ($(CROSSDEV),arm-nuttx-elf-)
> LDFLAGS += -nostartfiles -nodefaultlibs
> endif
> ifeq ($(CONFIG_DEBUG_SYMBO
Research, LLC
(240) 631-0008
- Original Message -
From: "Nathan Hartman"
To: dev@nuttx.apache.org
Sent: Thursday, March 19, 2020 10:39:39 AM
Subject: Re: Build errors with inline functions
On Thu, Mar 19, 2020 at 9:17 AM John Rippetoe
wrote:
> I am working on a new board po
On Thu, Mar 19, 2020 at 9:17 AM John Rippetoe
wrote:
> I am working on a new board port for the STM32H7 that's not yet in the
> repo. However, the same issue occurs when trying to build the existing
> H7 boards and with many of the F7 boards as well. All of the affected
> configs are flat builds,
I am working on a new board port for the STM32H7 that's not yet in the
repo. However, the same issue occurs when trying to build the existing
H7 boards and with many of the F7 boards as well. All of the affected
configs are flat builds, including my own. The functions the compiler
is complaini
Hi,
What config are you trying to build?
Did you try to run a clean build?
I built a couple of the protected mode STM32 boards, they all build
with no error.
On Wed, Mar 18, 2020 at 8:35 PM John Rippetoe
wrote:
>
> Hello,
>
> I updated master on my repo yesterday and noticed that I can no longe
Hello,
I updated master on my repo yesterday and noticed that I can no longer
build STM32H7 or F7 based boards. The compiler error in question is
shown below. For what its worth, I am using standard arm-none-eabi
toolchain on Ubuntu Linux.
LD: nuttx
nuttx/staging/libarch.a(stm32_allocatehea
34 matches
Mail list logo
