Re: No output for lm3s6965-ek:qemu-protected

2024-05-13 Thread Alan C. Assis
Hi Robin,

Did you test previous release versions? It could be useful to know in which
version the issue was introduced.

After that we could use git bisect to pinpoint the commit that introduced
this issues.

Best Regards,

Alan

On Mon, May 13, 2024 at 5:41 PM Robin Randhawa 
wrote:

> Hi.
>
> I find that:
>
> $ ./tools/configure.sh lm3s6965-ek:qemu-flat
> $ make
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic
>
> .. gets me to a nice NSH prompt with ping working.
>
> However, the following:
>
> $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> $ make
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic
>
> .. gets me:
>
> 
>
> Timer with period zero, disabling
> ABCEF
>
> 
>
> .. with no other output.
>
> Adding qemu logging after disabling translation block chaining using:
>
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:21 -kernel nuttx -nographic -d nochain,in_asm -D /tmp/qemu.log
>
> .. and processing the log like so gives me (with apologies for the
> verbosity):
>
> $ cat /tmp/qemu.log | grep ^IN | awk '!seen[$0]++' | nl
> 1  IN: __start
> 2  IN: tiva_clock_configure
> 3  IN: tiva_clock_reconfigure
> 4  IN: tiva_lowsetup
> 5  IN: modifyreg32
> 6  IN: tiva_configgpio
> 7  IN: tiva_gpiobaseaddress
> 8  IN: tiva_gpiofunc
> 9  IN: tiva_gpiowrite
> 10  IN: arm_lowputc
> 11  IN: memset
> 12  IN: memcpy
> 13  IN: tiva_userspace
> 14  IN: tiva_mpuinitialize
> 15  IN: mpu_configure_region
> 16  IN: mpu_allocregion
> 17  IN: mpu_log2regionceil
> 18  IN: mpu_subregion
> 19  IN: mpu_control
> 20  IN: tiva_boardinitialize
> 21  IN: lm_ssidev_initialize
> 22  IN: board_autoled_initialize
> 23  IN: nx_start
> 24  IN: strlcpy
> 25  IN: up_allocate_heap
> 26  IN: mpu_log2regionfloor
> 27  IN: board_autoled_on
> 28  IN: tiva_mpu_uheap
> 29  IN: umm_initialize
> 30  IN: mm_initialize
> 31  IN: nxmutex_init
> 32  IN: nxsem_init
> 33  IN: nxsem_set_protocol
> 34  IN: mm_addregion
> 35  IN: mm_lock
> 36  IN: nxsched_gettid
> 37  IN: nxmutex_lock
> 38  IN: nxsem_wait
> 39  IN: nxsched_remove_readytorun
> 40  IN: nxsched_add_prioritized
> 41  IN: up_switch_context
> 42  IN: exception_common
> 43  IN: arm_doirq
> 44  IN: arm_ack_irq
> 45  IN: irq_dispatch
> 46  IN: irq_unexpected_isr
> 47  IN: syslog
> 48  IN: vsyslog
> 49  IN: nx_vsyslog
> 50  IN: lib_syslograwstream_open
> 51  IN: lib_vsprintf_internal
> 52  IN: vsprintf_internal.constprop.0
> 53  IN: strnlen
> 54  IN: syslograwstream_puts
> 55  IN: syslog_write
> 56  IN: syslograwstream_putc
> 57  IN: syslog_putc
> 58  IN: __ultoa_invert
> 59  IN: __aeabi_uldivmod
> 60  IN: __udivmoddi4
> 61  IN: __assert
> 62  IN: _assert
> 63  IN: up_saveusercontext
> 64  IN: panic_notifier_call_chain
> 65  IN: syslog_flush
> 66  IN: uname
> 67  IN: gethostname
> 68  IN: snprintf
> 69  IN: lib_memoutstream
> 70  IN: lib_vsprintf
> 71  IN: memoutstream_puts
> 72  IN: memoutstream_putc
> 73  IN: up_dump_register
> 74  IN: up_getusrsp
> 75  IN: up_check_tcbstack
> 76  IN: arm_stack_check
> 77  IN: stack_dump
> 78  IN: nxsched_foreach
> 79  IN: sched_lock
> 80  IN: sched_unlock
> 81  IN: reboot_notifier_call_chain
> 82  IN: up_mdelay
> 83  IN: board_autoled_off
>
> I assume this is unexpected ? If not, I'd appreciate any insights.
>
> Thanks,
> Robin
>


Re: No output for lm3s6965-ek:qemu-protected

2024-05-14 Thread Robin Randhawa
Hi Alan.

Thanks for the response.

I forgot to add that I had tried to bisect things but I didn't get very far.
This could be down to something silly at my end but either I couldn't get a
successful build or I would hit the same situation as previously indicated.

I decided to poke a bit further and have some points to share in the hope
that they help:

I went back to the first commit where support for this board was added like
so:

$ cd nuttx

$ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
configs/qemu-protected/defconfig | tail -n 2
702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
configs for qemu

$ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521

$ ./tools/configure.sh lm3s6965-ek:qemu-protected

$ make -j(nproc)

.. which ended with:

===
AR (create): libboard.a   lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
lm_appinit.o lm_bringup.o
make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
arm/tiva/lm3s6965-ek/src'
LD: nuttx
arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
mean --nostartfiles ?)
make[1]: *** [Makefile:172: nuttx] Error 1
make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
make: *** [tools/Makefile.unix:412: nuttx] Error 2
===

I 'fixed' that by omitting the offending ld switches manually. I then got
the following:

$ qemu-system-arm \
-M lm3s6965evb\
-net nic,model=stellaris -net user,hostfwd=tcp:127.0.0.1:10023-
10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21 \
-kernel nuttx -nographic
Timer with period zero, disabling
ABCDup_assert: Assertion failed at file:chip/common/tiva_userspace.c line:
87
irq_unexpected_isr: ERROR irq: 11
up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
up_registerdump: R0:  20001e58 000a 2474  
20002f8c 2468
up_registerdump: R8:     0008 20002f88
60e7 67a6
up_registerdump: xPSR: 61000200 PRIMASK:  CONTROL: 
up_registerdump: EXC_RETURN: fff9
up_dumpstate: sp: 20002ec8
up_dumpstate: stack base: 04d1
up_dumpstate: stack size: 04d1
up_dumpstate: ERROR: Stack pointer is not within the allocated stack
up_stackdump: : 20002fe4 011d 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 0020: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 0040: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 0060: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 0080: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 00a0: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 00c0: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 00e0: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 04d1
up_stackdump: 0100: 04d1 04d1 04d1 04d1 04d1
04d1 04d1 f000b508
up_stackdump: 0120: f000f8b1 2041fa15 fa0af000 4b172100 42934a17
2042d321 fa02f000 4a164b15
up_stackdump: 0140: 428b4916 2043d31c f9faf000 fb12f000 f0002044
f000f9f5 2045f89d f9f0f000
up_stackdump: 0160: f970f001 f0002046 200df9eb f9e8f000 f000200a
f001f9e5 f843f9a5 e7d81b04

I took care to ensure that my apps directory was reset to a date that
corresponded to the commit used for the nuttx directory.

Interestingly - and as indicated in my first post - a build with the latest
nuttx and apps dirs doesn't produce the above output. However, when I look
at my poor person's 'boot log' I see the same invocation of
irq_unexpected_isr.

My theory, therefore, is that lm3s6965-ek:qemu-protected has never worked
ever since support was committed ?
Also: I think the unexpected IRQ 11 (that's an SVC exception I think ?) has
been the problem since the beginning and continues to manifest even with
the latest nuttx.

I would appreciate any advice. I will try and explore a bit further myself
but I am very new to NuttX.

Cheers,
Robin

On Mon, 13 May 2024 at 22:35, Alan C. Assis  wrote:

> Hi Robin,
>
> Did you test previous release versions? It could be useful to know in which
> version the issue was introduced.
>
> After that we could use git bisect to pinpoint the commit that introduced
> this issues.
>
> Best Regards,
>
> Alan
>
> On Mon, May 13, 2024 at 5:41 PM Robin Randhawa 
> wrote:
>
> > Hi.
> >
> > I find that:
> >
> > $ ./tools/configure.sh lm3s6965-ek:qemu-flat
> > $ make
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=
> tcp:127.0.0.1:10021-
> > 10.0.2.15:21 -kernel nuttx -nographic
> >
> > .. gets me to a nice NSH prompt with ping working.
> >
> > However, the following:
> >
> > $ ./tools/configure.sh lm3s6965-ek:qemu-pr

Re: No output for lm3s6965-ek:qemu-protected

2024-05-14 Thread Alan C. Assis
Hi Robin,

Thank you very much for further investigation!

I tried to build here and found a different issue:

CC:  wchar/lib_mbsnrtowcs.c MODULECC: chardev.c
CC:  proxies/PROXY_dup2.c LD: struct_main.o
LD: hello.o
CC:  readline.c LD: task.o
LD: signal.o
MODULELD: chardev.o
CC:  nsh_envcmds.c LD: pthread.o
LD: mutex.o
arm-none-eabi-ld: nuttx_user.elf section `.data' will not fit in region
`uflash'
arm-none-eabi-ld: region `uflash' overflowed by 64 bytes
make[1]: *** [Makefile:59: nuttx_user.elf] Error 1
make: *** [tools/Unix.mk:535: nuttx] Error 2

After disabling some tools (i.e. wget) I was able to compile, but faced
similar issue as you:

$ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
10.0.2.15:1021
Timer with period zero, disabling
qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)

R00= R01= R02= R03=
R04= R05= R06= R07=
R08= R09= R10= R11=
R12= R13=ffe0 R14=fff9 R15=
XPSR=4003 -Z-- A handler
FPSCR: 

This commit was added in 2021 by Yamamoto-san, so I'm CC here, maybe we
could give more details or have some idea what could be the issue.

It is important to know the root causes of the issue, it could be something
related to your toolchain as well

Looking at boards/ I noticed that qemu-kostest and qemu-protected are the
only ones QEMU configs with CONFIG_BUILD_PROTECTED=y enabled.

There are other board profiles that you can test on real boards.

Best Regards,

Alan

On Tue, May 14, 2024 at 2:12 PM Robin Randhawa 
wrote:

> Hi Alan.
>
> Thanks for the response.
>
> I forgot to add that I had tried to bisect things but I didn't get very
> far.
> This could be down to something silly at my end but either I couldn't get a
> successful build or I would hit the same situation as previously indicated.
>
> I decided to poke a bit further and have some points to share in the hope
> that they help:
>
> I went back to the first commit where support for this board was added like
> so:
>
> $ cd nuttx
>
> $ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
> configs/qemu-protected/defconfig | tail -n 2
> 702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
> configs for qemu
>
> $ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521
>
> $ ./tools/configure.sh lm3s6965-ek:qemu-protected
>
> $ make -j(nproc)
>
> .. which ended with:
>
> ===
> AR (create): libboard.a   lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
> lm_appinit.o lm_bringup.o
> make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
> arm/tiva/lm3s6965-ek/src'
> LD: nuttx
> arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
> mean --nostartfiles ?)
> make[1]: *** [Makefile:172: nuttx] Error 1
> make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
> make: *** [tools/Makefile.unix:412: nuttx] Error 2
> ===
>
> I 'fixed' that by omitting the offending ld switches manually. I then got
> the following:
>
> $ qemu-system-arm \
> -M lm3s6965evb\
> -net nic,model=stellaris -net user,hostfwd=tcp:127.0.0.1:10023-
> 10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21 \
> -kernel nuttx -nographic
> Timer with period zero, disabling
> ABCDup_assert: Assertion failed at file:chip/common/tiva_userspace.c line:
> 87
> irq_unexpected_isr: ERROR irq: 11
> up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> up_registerdump: R0:  20001e58 000a 2474  
> 20002f8c 2468
> up_registerdump: R8:     0008 20002f88
> 60e7 67a6
> up_registerdump: xPSR: 61000200 PRIMASK:  CONTROL: 
> up_registerdump: EXC_RETURN: fff9
> up_dumpstate: sp: 20002ec8
> up_dumpstate: stack base: 04d1
> up_dumpstate: stack size: 04d1
> up_dumpstate: ERROR: Stack pointer is not within the allocated stack
> up_stackdump: : 20002fe4 011d 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0020: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0040: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0060: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0080: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 00a0: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 00c0: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 00e0: 04d1 04d1 04d1 04d1 04d1
> 04d1 04d1 04d1
> up_stackdump: 0100: 04d1 04d1 04d1 04d1 04d1
> 04d1 0

Re: No output for lm3s6965-ek:qemu-protected

2024-05-14 Thread Robin Randhawa
Thanks Alan!

Would be great to get Yamamoto-San's views.

Basically I want to showcase Nuttx as a good option for misc projects and
the situation is such that I need the following attributes:

1. Cortex-M
2. Ethernet
3. Qemu

Unless I'm mistaken, lm3s6965evb was the only board that met all 3 ?

Cheers,
Robin

On Tue, 14 May 2024 at 18:48, Alan C. Assis  wrote:

> Hi Robin,
>
> Thank you very much for further investigation!
>
> I tried to build here and found a different issue:
>
> CC:  wchar/lib_mbsnrtowcs.c MODULECC: chardev.c
> CC:  proxies/PROXY_dup2.c LD: struct_main.o
> LD: hello.o
> CC:  readline.c LD: task.o
> LD: signal.o
> MODULELD: chardev.o
> CC:  nsh_envcmds.c LD: pthread.o
> LD: mutex.o
> arm-none-eabi-ld: nuttx_user.elf section `.data' will not fit in region
> `uflash'
> arm-none-eabi-ld: region `uflash' overflowed by 64 bytes
> make[1]: *** [Makefile:59: nuttx_user.elf] Error 1
> make: *** [tools/Unix.mk:535: nuttx] Error 2
>
> After disabling some tools (i.e. wget) I was able to compile, but faced
> similar issue as you:
>
> $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-
> 10.0.2.15:1021
> Timer with period zero, disabling
> qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
>
> R00= R01= R02= R03=
> R04= R05= R06= R07=
> R08= R09= R10= R11=
> R12= R13=ffe0 R14=fff9 R15=
> XPSR=4003 -Z-- A handler
> FPSCR: 
>
> This commit was added in 2021 by Yamamoto-san, so I'm CC here, maybe we
> could give more details or have some idea what could be the issue.
>
> It is important to know the root causes of the issue, it could be something
> related to your toolchain as well
>
> Looking at boards/ I noticed that qemu-kostest and qemu-protected are the
> only ones QEMU configs with CONFIG_BUILD_PROTECTED=y enabled.
>
> There are other board profiles that you can test on real boards.
>
> Best Regards,
>
> Alan
>
> On Tue, May 14, 2024 at 2:12 PM Robin Randhawa 
> wrote:
>
> > Hi Alan.
> >
> > Thanks for the response.
> >
> > I forgot to add that I had tried to bisect things but I didn't get very
> > far.
> > This could be down to something silly at my end but either I couldn't
> get a
> > successful build or I would hit the same situation as previously
> indicated.
> >
> > I decided to poke a bit further and have some points to share in the hope
> > that they help:
> >
> > I went back to the first commit where support for this board was added
> like
> > so:
> >
> > $ cd nuttx
> >
> > $ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
> > configs/qemu-protected/defconfig | tail -n 2
> > 702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
> > configs for qemu
> >
> > $ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521
> >
> > $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> >
> > $ make -j(nproc)
> >
> > .. which ended with:
> >
> > ===
> > AR (create): libboard.a   lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
> > lm_appinit.o lm_bringup.o
> > make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
> > arm/tiva/lm3s6965-ek/src'
> > LD: nuttx
> > arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
> > mean --nostartfiles ?)
> > make[1]: *** [Makefile:172: nuttx] Error 1
> > make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
> > make: *** [tools/Makefile.unix:412: nuttx] Error 2
> > ===
> >
> > I 'fixed' that by omitting the offending ld switches manually. I then got
> > the following:
> >
> > $ qemu-system-arm \
> > -M lm3s6965evb\
> > -net nic,model=stellaris -net user,hostfwd=tcp:127.0.0.1:10023-
> > 10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21 \
> > -kernel nuttx -nographic
> > Timer with period zero, disabling
> > ABCDup_assert: Assertion failed at file:chip/common/tiva_userspace.c
> line:
> > 87
> > irq_unexpected_isr: ERROR irq: 11
> > up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> > up_registerdump: R0:  20001e58 000a 2474 
> 
> > 20002f8c 2468
> > up_registerdump: R8:     0008
> 20002f88
> > 60e7 67a6
> > up_registerdump: xPSR: 61000200 PRIMASK:  CONTROL: 
> > up_registerdump: EXC_RETURN: fff9
> > up_dumpstate: sp: 20002ec8
> > up_dumpstate: stack base: 04d1
> > up_dumpstate: stack size: 04d1
> > up_dumpstate: ERROR: Stack pointer is not within the allocated stack
> > up_stackdump: : 20002fe4 011d 04d1 04d1 04d1
> > 04d1 04d1 04d1
> > up_stackdump: 0020: 04d1 04d1 04d1 04d1 04d1
> > 04d1 04d1 04d1
> > up_stackdump: 0040: 04d1 04d1 04d1 04d1 04d1

Re: No output for lm3s6965-ek:qemu-protected

2024-05-14 Thread Alan C. Assis
Exactly! Since you require Cortex-M, Ethernet and QEMU.

I'm not sure if the qemu-system-arm package now has support for STM32, if
it has it is possible to use some stm32 board.

Another alternative could be RISC-V on QEMU, in case Cortex-M is not an
essential requirement.

Ah, and Xtensa (ESP32) also has support on QEMU, which is also an
alternative (since it also supports Ethernet).

Best Regards,

Alan

On Tue, May 14, 2024 at 3:01 PM Robin Randhawa 
wrote:

> Thanks Alan!
>
> Would be great to get Yamamoto-San's views.
>
> Basically I want to showcase Nuttx as a good option for misc projects and
> the situation is such that I need the following attributes:
>
> 1. Cortex-M
> 2. Ethernet
> 3. Qemu
>
> Unless I'm mistaken, lm3s6965evb was the only board that met all 3 ?
>
> Cheers,
> Robin
>
> On Tue, 14 May 2024 at 18:48, Alan C. Assis  wrote:
>
> > Hi Robin,
> >
> > Thank you very much for further investigation!
> >
> > I tried to build here and found a different issue:
> >
> > CC:  wchar/lib_mbsnrtowcs.c MODULECC: chardev.c
> > CC:  proxies/PROXY_dup2.c LD: struct_main.o
> > LD: hello.o
> > CC:  readline.c LD: task.o
> > LD: signal.o
> > MODULELD: chardev.o
> > CC:  nsh_envcmds.c LD: pthread.o
> > LD: mutex.o
> > arm-none-eabi-ld: nuttx_user.elf section `.data' will not fit in region
> > `uflash'
> > arm-none-eabi-ld: region `uflash' overflowed by 64 bytes
> > make[1]: *** [Makefile:59: nuttx_user.elf] Error 1
> > make: *** [tools/Unix.mk:535: nuttx] Error 2
> >
> > After disabling some tools (i.e. wget) I was able to compile, but faced
> > similar issue as you:
> >
> > $ qemu-system-arm -M lm3s6965evb -net nic,model=stellaris -net
> > user,hostfwd=tcp:127.0.0.1:10023-10.0.2.15:23
> ,hostfwd=tcp:127.0.0.1:10021-
> > 10.0.2.15:1021
> > Timer with period zero, disabling
> > qemu: fatal: Lockup: can't escalate 3 to HardFault (current priority -1)
> >
> > R00= R01= R02= R03=
> > R04= R05= R06= R07=
> > R08= R09= R10= R11=
> > R12= R13=ffe0 R14=fff9 R15=
> > XPSR=4003 -Z-- A handler
> > FPSCR: 
> >
> > This commit was added in 2021 by Yamamoto-san, so I'm CC here, maybe we
> > could give more details or have some idea what could be the issue.
> >
> > It is important to know the root causes of the issue, it could be
> something
> > related to your toolchain as well
> >
> > Looking at boards/ I noticed that qemu-kostest and qemu-protected are the
> > only ones QEMU configs with CONFIG_BUILD_PROTECTED=y enabled.
> >
> > There are other board profiles that you can test on real boards.
> >
> > Best Regards,
> >
> > Alan
> >
> > On Tue, May 14, 2024 at 2:12 PM Robin Randhawa  >
> > wrote:
> >
> > > Hi Alan.
> > >
> > > Thanks for the response.
> > >
> > > I forgot to add that I had tried to bisect things but I didn't get very
> > > far.
> > > This could be down to something silly at my end but either I couldn't
> > get a
> > > successful build or I would hit the same situation as previously
> > indicated.
> > >
> > > I decided to poke a bit further and have some points to share in the
> hope
> > > that they help:
> > >
> > > I went back to the first commit where support for this board was added
> > like
> > > so:
> > >
> > > $ cd nuttx
> > >
> > > $ git whatchanged --pretty=oneline boards/arm/tiva/lm3s6965-ek/
> > > configs/qemu-protected/defconfig | tail -n 2
> > > 702bc95cac16fe90cfaf8abb178b0822ba707521 tiva/lm3s6965-ek: Add a few
> > > configs for qemu
> > >
> > > $ git checkout -b test 702bc95cac16fe90cfaf8abb178b0822ba707521
> > >
> > > $ ./tools/configure.sh lm3s6965-ek:qemu-protected
> > >
> > > $ make -j(nproc)
> > >
> > > .. which ended with:
> > >
> > > ===
> > > AR (create): libboard.a   lm_boot.o lm_leds.o lm_ethernet.o lm_ssi.o
> > > lm_appinit.o lm_bringup.o
> > > make[2]: Leaving directory 'nuttx_workspace/nuttx/boards/
> > > arm/tiva/lm3s6965-ek/src'
> > > LD: nuttx
> > > arm-none-eabi-ld: Error: unable to disambiguate: -nostartfiles (did you
> > > mean --nostartfiles ?)
> > > make[1]: *** [Makefile:172: nuttx] Error 1
> > > make[1]: Leaving directory 'nuttx_workspace/nuttx/arch/arm/src'
> > > make: *** [tools/Makefile.unix:412: nuttx] Error 2
> > > ===
> > >
> > > I 'fixed' that by omitting the offending ld switches manually. I then
> got
> > > the following:
> > >
> > > $ qemu-system-arm \
> > > -M lm3s6965evb\
> > > -net nic,model=stellaris -net user,hostfwd=tcp:127.0.0.1
> :10023-
> > > 10.0.2.15:23,hostfwd=tcp:127.0.0.1:10021-10.0.2.15:21 \
> > > -kernel nuttx -nographic
> > > Timer with period zero, disabling
> > > ABCDup_assert: Assertion failed at file:chip/common/tiva_userspace.c
> > line:
> > > 87
> > > irq_unexpected_isr: ERROR irq: 11
> > > up_assert: Assertion failed at file:irq/irq_unexpectedisr.c line: 50
> > > up_registerdump: R0:  20001e58 000a