Porting NuttX - console management trouble
Hello, I am currently in the process of porting NuttX to the i.MX8MP (Cortex-M7) SoC from NXP. I managed to have a POC that boot and the serial seems to work properly. However the console seems to behave strangely: I need to configure my client to handle the echo and to transform input and output. An example with picocom client: picocom -b 115200 --omap crlf --imap lfcrlf --echo /dev/ttyUSB2 This seems to be unnecessary on other targets (I tried on a picopi and on an xmc4700). Is it a normal behavior? If not is someone have any clues to track this bug? Thank you in advance, Best regards, -- Philippe LEDUC philippe.le...@mailfence.com
Re: Porting NuttX - console management trouble
Hi Philippe, On 8/18/23, Philippe Leduc wrote: > Hello, > > I am currently in the process of porting NuttX to the i.MX8MP (Cortex-M7) > SoC Did you see that: https://github.com/apache/nuttx/pull/10294 Maybe you can reuse or merge part of it. > from NXP. I managed to have a POC that boot and the serial seems to work > properly. However the console seems to behave strangely: I need to configure > my > client to handle the echo and to transform input and output. An example with > > picocom client: > picocom -b 115200 --omap crlf --imap lfcrlf --echo /dev/ttyUSB2 > > This seems to be unnecessary on other targets (I tried on a picopi and on an > > xmc4700). > > Is it a normal behavior? If not is someone have any clues to track this > bug? > It should work without these parameters. Did you try minicom as well? Try to force the ttyUSBx to use the expected configuration for NuttX (115200 8N1) # stty 115200 cs8 -parenb -crtscts -F /dev/ttyUSB0 Maybe the serial controller of i.MX8 has some peculiarity that needs to be considered. BR, Alan
Re: Porting NuttX - console management trouble
On 8/18/2023 12:14 PM, Philippe Leduc wrote: Hello, I am currently in the process of porting NuttX to the i.MX8MP (Cortex-M7) SoC from NXP. I managed to have a POC that boot and the serial seems to work properly. However the console seems to behave strangely: I need to configure my client to handle the echo and to transform input and output. An example with picocom client: picocom -b 115200 --omap crlf --imap lfcrlf --echo /dev/ttyUSB2 This seems to be unnecessary on other targets (I tried on a picopi and on an xmc4700). Is it a normal behavior? If not is someone have any clues to track this bug? Thank you in advance, Best regards, Sounds like the console device is in RAW mode. For proper NSH behavior, the console TTY must be configured in COOKED mode. That configuration should occur automatically if the uart was configured as the serial console. I suppose that could use the termios interfaces to force COOKED mode, but should not be necessary. Do you have a serial port configured as console device (in drivers/serial)? Do you have picocom connected to that uart port? If so then you probably have some error in your configuration so that the uart is not recognized as the console device in drivers/serial/serial.c Is /dev/ttyUSB2 a USB serial adaptor? Or are you trying to use a USB port for console?
Re: Small annoyances when building NuttX on FreeBSD
On Wed, 16 Aug 2023 16:29:11 +0200 I wrote: > On Wed, 16 Aug 2023 14:32:23 +0200 > Bernd Walter wrote: > > > On Wed, Aug 16, 2023 at 11:18:19AM +0200, Milan Obuch wrote: [ snip ] > > > Additionally, for Raspberry Pi Pico, there is one more error > > > message, this time somewhat serious: > > > > > > Generating: nuttx.uf2 > > > tools/rp2040/elf2uf2 nuttx nuttx.uf2; > > > ld-elf.so.1: /usr/local/lib/gcc10/libstdc++.so.6: version > > > GLIBCXX_3.4.29 required by > > > /wrk/usr/ports/devel/apache-nuttx/work/nuttx/tools/rp2040/elf2uf2 > > > not found gmake: *** [tools/Unix.mk:541: nuttx] Error 1 > > > > > > and, consequently, nuttx.uf2 file for uploading to the board is > > > not prepared. This is not fatal for me, because I can execute > > > command > > > > > > /wrk/pico/pico-examples/build/elf2uf2/elf2uf2 -v nuttx > > > nuttx.bin.uf2 > > > > > > manually and got it. Again, it would be nice to fix this. In my > > > eyes, the preferable way for this would be just using already > > > available elf2uf2 binary, either in path, or, maybe, with > > > explicitly assigned via some ELF2UF2= assignment. The > > > PICO_SDK_PATH=/wrk/pico/pico-sdk assignment used above is just for > > > building this binary. I'd prefer to do it just once as part of > > > working setup preparation and not for every build, which could be > > > just done the way I mentioned. > > > > > > I run into that problem as well. > > It is very specific to the RP2040 build and Nuttx compiles some kind > > of tool, but uses a disfunctional GCC version, because it doesn't > > use the system compiler. > > Unfortunately the broken compiler is a dependency of the xtensa > > compiler toolchain. > > So you either have the xtensa build tools or you compile for RP2040. > > > > This is my local workaround: > > diff --git a/contrib/nuttx/tools/rp2040/Makefile.host > > b/contrib/nuttx/tools/rp2040/Makefile.host index > > 32717c11f7..aada7f9709 100644 --- > > a/contrib/nuttx/tools/rp2040/Makefile.host +++ > > b/contrib/nuttx/tools/rp2040/Makefile.host @@ -28,7 +28,7 @@ CFLAGS > > = -O2 -std=c++14 CFLAGS += > > -I$(PICO_SDK_PATH)/src/common/boot_uf2/include > > elf2uf2: $(PICO_SDK_PATH)/tools/elf2uf2/main.cpp > > - @g++ $(CFLAGS) -o $@ $< > > + @c++ $(CFLAGS) -o $@ $< > > > > clean: > > @rm -f *.o *.a *.dSYM *~ .*.swp > > > > Thanks, I suspected something like this, I did not analyzed it > thoroughly. I can live with this now, as I use jail for NuttX builds, > I can as easily use additional one for RP2040... I'll see later. > Note: using 12.0.0 sources, this problem does not occur. It looks like there was some change in build process after 12.0.0 was released. Regards, Milan
