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=00000000 R01=00000000 R02=00000000 R03=00000000 R04=00000000 R05=00000000 R06=00000000 R07=00000000 R08=00000000 R09=00000000 R10=00000000 R11=00000000 R12=00000000 R13=ffffffe0 R14=fffffff9 R15=00000000 XPSR=40000003 -Z-- A handler FPSCR: 00000000 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 <robin.randh...@gmail.com> 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: 00000000 20001e58 0000000a 20000474 00000000 00000000 > 20002f8c 20000468 > up_registerdump: R8: 00000000 00000000 00000000 00000000 00000008 20002f88 > 000060e7 000067a6 > up_registerdump: xPSR: 61000200 PRIMASK: 00000000 CONTROL: 00000000 > up_registerdump: EXC_RETURN: fffffff9 > up_dumpstate: sp: 20002ec8 > up_dumpstate: stack base: 000004d1 > up_dumpstate: stack size: 000004d1 > up_dumpstate: ERROR: Stack pointer is not within the allocated stack > up_stackdump: 00000000: 20002fe4 0000011d 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 00000020: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 00000040: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 00000060: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 00000080: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 000000a0: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 000000c0: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 000000e0: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 000004d1 > up_stackdump: 00000100: 000004d1 000004d1 000004d1 000004d1 000004d1 > 000004d1 000004d1 f000b508 > up_stackdump: 00000120: f000f8b1 2041fa15 fa0af000 4b172100 42934a17 > 2042d321 fa02f000 4a164b15 > up_stackdump: 00000140: 428b4916 2043d31c f9faf000 fb12f000 f0002044 > f000f9f5 2045f89d f9f0f000 > up_stackdump: 00000160: 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 <acas...@gmail.com> 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 <robin.randh...@gmail.com > > > > 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 > > > > > >
