On Wed, Nov 9, 2022 at 4:14 AM Sebastien Lorquet
wrote:
> Hello,
>
> I also suggest avoiding this, magical things happening without user
> notification are bound to generate day long debugging headaches. At
> least make it very clear somewhere (build output) about what linker
> script is used.
Hello,
I also suggest avoiding this, magical things happening without user
notification are bound to generate day long debugging headaches. At
least make it very clear somewhere (build output) about what linker
script is used.
For example in the final link step, which is rather terse in most
Hello,
Please don't dont that. Linker scripts are per board (I have my own
bootloader) but also per chip, since the chip flash is not mapped the
same on all arm microcontrollers.
But you can provide templates and docs as references of the mandatory
sections that have to be included, and in w
On 11/4/22, Nathan Hartman wrote:
> On Fri, Nov 4, 2022 at 4:32 PM Alan C. Assis wrote:
>
>> Hi Nathan,
>>
>> Do you have some other idea?
>>
>> "Just add another symbol" is not a good idea.
>>
>> We are going to pass Linux kernel Kconfig is one day or two :-)
>>
>> I think we need to simplify ou
On Fri, Nov 4, 2022 at 4:32 PM Alan C. Assis wrote:
> Hi Nathan,
>
> Do you have some other idea?
>
> "Just add another symbol" is not a good idea.
>
> We are going to pass Linux kernel Kconfig is one day or two :-)
>
> I think we need to simplify our Kconfig, not to make each more complex
> ever
Hi Nathan,
Do you have some other idea?
"Just add another symbol" is not a good idea.
We are going to pass Linux kernel Kconfig is one day or two :-)
I think we need to simplify our Kconfig, not to make each more complex
every single day.
BR,
Alan
On 11/4/22, Nathan Hartman wrote:
> On Fri,
On Fri, Nov 4, 2022 at 4:06 PM Nathan Hartman
wrote:
> On Fri, Nov 4, 2022 at 2:12 PM Carlos Sanchez
> wrote:
>
>> It is exactly the same issue, I should have checked there, apologies for
>> duplicating. Shall we continue the discussion there?
>>
>> In any case, I do not think it is such an unco
On Fri, Nov 4, 2022 at 2:12 PM Carlos Sanchez
wrote:
> It is exactly the same issue, I should have checked there, apologies for
> duplicating. Shall we continue the discussion there?
>
> In any case, I do not think it is such an uncommon scenario... We have hit
> it in our application (that is w
It is exactly the same issue, I should have checked there, apologies for
duplicating. Shall we continue the discussion there?
In any case, I do not think it is such an uncommon scenario... We have hit
it in our application (that is why we saw it). I mostly agree with the OP
of the original bug re
I think this issue is related?
https://github.com/apache/incubator-nuttx/issues/2001
On Thu, Nov 3, 2022 at 9:12 PM Alan C. Assis wrote:
> Hi Carlos,
>
> I tested and confirmed the issue:
>
> $ patch -p1 <
> ~/Desktop/0001-Changes-to-force-fill-bss-section-causing-sp-past-th.patch
> patching f
Hi Carlos,
I tested and confirmed the issue:
$ patch -p1 <
~/Desktop/0001-Changes-to-force-fill-bss-section-causing-sp-past-th.patch
patching file arch/arm/src/armv7-m/arm_vectors.c
$ ./tools/configure.sh lm3s6965-ek:qemu-flat
$ make -j8
$ qemu-system-arm -semihosting \
-M lm3s6965ev
Hi all,
I have detected the armv{6,7,8}-m/arm_vectors.c assigns the initial
stack pointer value (using the first entry at the exception vectors
table) just to _ebss + CONFIG_IDLETHREAD_STACKSIZE, without further
checking. This can yield to an unusable binary if .data or .bss
sections grow too much
12 matches
Mail list logo
