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 <robin.randh...@gmail.com> 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 <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 > > > > > > > > > > > > > > >
