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 <acas...@gmail.com> 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=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 > > > > > > > > > >
