In the past (9 or so years ago) there was an issue with floating point that
required the stack to be 8 byte aligned. It was too long ago, so I do not
remember the details, j
(There is a note in the release notes, "ARM EABI: Fix stack alignment
required for passing floating point values.") But I
Hi Johannes & Jukka,
Thank you for looking into this, I just wanted to mention something, so it
does not get over looked, if it is still appropriate:
In the past (9 or so years ago) there was an issue with floating point that
required the stack to be 8 byte aligned. It was too long ago, so I do n
Sorry for the typo: will be use a bad block -> will not use a bad block
On 9/25/20, Alan Carvalho de Assis wrote:
> Hi Thomas,
>
> According to drivers/mtd/README.txt the NAND support is only partial
> because there is not a FS to handle it correctly.
>
> Normally for NAND you will need to scan t
Hi Thomas,
According to drivers/mtd/README.txt the NAND support is only partial
because there is not a FS to handle it correctly.
Normally for NAND you will need to scan the NAND to update the bad
block table during the boot (could be on NuttX or in a bootloader) to
guarantee the FS will be use a
I'm trying to understand what level of NAND memory support currently exists in
NuttX. The intention is to read and write files on the NAND memory.
Device level support is in place, but probably somewhat out of date.
The obstacle to use NAND is that there is no NAND-compatibile file
system o
> 1. Set the stack size as aligned already in
> arch/arm/src/common/arm_createstack.c:
>
> - tcb->adj_stack_size = stack_size;
> + tcb->adj_stack_size = STACK_ALIGN_DOWN(stack_size);
>
> 2. fix the do_stackcheck in a way that it doesn't start at (unaligned)
> top, but at the first align
Hi,
I'm trying to understand what level of NAND memory support currently exists in
NuttX. The intention is to read and write files on the NAND memory.
I have found CONFIG_MTD_NAND and there seems to be a NAND driver for the SAMA5
built-in NAND. All other MTD drivers appear to be for NOR? The in
Is this happening on master as well? I've commited a change (#1562 ) to ARM
stack management not long ago.
Perhaps I missed something.
I'll have a look.
Johannes
> I just encountered a problem with do_stackcheck(), and wanted to ask for
> an opinion...
>
> In my (PX4) software I have got some t
Hi!
I just encountered a problem with do_stackcheck(), and wanted to ask for
an opinion...
In my (PX4) software I have got some threads, who define their stack
size unaligned by 4 bytes (uint32_t). The stack coloring works on
uint32, and thus doesn't color the topmost bytes of the stack whe
