Re: riscv64 libm link question
On Mon, Sep 18, 2023 at 7:01 AM Lee, Lup Yuen wrote: > Here's what Ken and I have tried for the riscv64 libm linking problem: > > (1) The recommended toolchain for NuttX on riscv64 is SiFive Freedom Tools. > But it doesn't support Raspberry Pi OS (64-bit Debian). > > (2) So we used Debian gcc-riscv64-unknown-elf instead. Which shows the > missing libm error that Ken described. > > (3) We're trying an alternative toolchain: xPack GNU RISC-V Embedded GCC. > Which might fix the libm problem, but we're not sure if it's supported for > NuttX. > > Lup, could you update the toolchain used by ci after you get a working new binary? ci is blocked by this now: https://github.com/apache/nuttx/issues/10594. > Wonder if anyone has tried building riscv64 NuttX on Raspberry Pi OS / > Arm64 Linux? More details below. Thanks! > > > https://lupyuen.github.io/articles/riscv#appendix-xpack-gnu-risc-v-embedded-gcc-toolchain-for-64-bit-risc-v > > https://lupyuen.github.io/articles/release#appendix-missing-mathh > > Lup > > On Mon, Sep 18, 2023 at 4:15 AM wrote: > > > On 2023-09-17 12:47, Petro Karashchenko wrote: > > > Hi, > > > > > > What kind of RISC-V toolchain are you using? > > > > Raspian:RasPi4:~/RISCV/NuttX/apps >>> apt search riscv64-unknown > > Sorting... Done > > Full Text Search... Done > > binutils-riscv64-unknown-elf/oldstable,now 2.32.2020.04+dfsg-2 arm64 > > [installed] > >GNU assembler, linker and binary utilities for RISC-V processors > > > > gcc-riscv64-unknown-elf/oldstable,now 8.3.0.2019.08+dfsg-1 arm64 > > [installed] > >GCC compiler for embedded RISC-V chips > > > > picolibc-riscv64-unknown-elf/oldstable,oldstable,now 1.5.1-2 all > > [installed] > >Smaller embedded C library for RISC-V development > > > > So just `sudo apt-get install ...` of the above. > > > > > Please try to remove "CFLAGS += -lm " and feedback if that helps. > > > > No change. > > > > The problem is not that I am trying to use some released libm library > > but that the NuttX nuttx/libs/libm/libm.a is not being linked into the > > scheme binary file. > > > > I have not used other than trivial makefiles in a couple of decades, > > never used `make menuconfig`, which allows one to specify many > > non-bootable systems, and so have little clue how to specify linking the > > NuttX libm into the scheme executable or alternately getting nuttx to > > dynamically load the libm library. > > > > Note that there is no file 'kconfig-language.txt' in the NuttX tools > > repository. > > > > I am kinda stuck. Thanks for any help! > > -KenD > > > > >
Re: riscv64 libm link question
On Mon, Sep 18, 2023 at 4:16 AM wrote: > On 2023-09-17 12:47, Petro Karashchenko wrote: > > Hi, > > > > What kind of RISC-V toolchain are you using? > > Raspian:RasPi4:~/RISCV/NuttX/apps >>> apt search riscv64-unknown > Sorting... Done > Full Text Search... Done > binutils-riscv64-unknown-elf/oldstable,now 2.32.2020.04+dfsg-2 arm64 > [installed] >GNU assembler, linker and binary utilities for RISC-V processors > > gcc-riscv64-unknown-elf/oldstable,now 8.3.0.2019.08+dfsg-1 arm64 > [installed] >GCC compiler for embedded RISC-V chips > > picolibc-riscv64-unknown-elf/oldstable,oldstable,now 1.5.1-2 all > [installed] >Smaller embedded C library for RISC-V development > > So just `sudo apt-get install ...` of the above. > > > Please try to remove "CFLAGS += -lm " and feedback if that helps. > > No change. > > The problem is not that I am trying to use some released libm library > but that the NuttX nuttx/libs/libm/libm.a is not being linked into the > scheme binary file. > > Do you build scheme as a separate elf image? > I have not used other than trivial makefiles in a couple of decades, > never used `make menuconfig`, which allows one to specify many > non-bootable systems, and so have little clue how to specify linking the > NuttX libm into the scheme executable or alternately getting nuttx to > dynamically load the libm library. > > Could you first try the builtin scheme work as expect? > Note that there is no file 'kconfig-language.txt' in the NuttX tools > repository. > > it host here: https://github.com/torvalds/linux/blob/master/Documentation/kbuild/kconfig-language.rst I am kinda stuck. Thanks for any help! > -KenD > >
Re: riscv64 libm link question
Here's what Ken and I have tried for the riscv64 libm linking problem: (1) The recommended toolchain for NuttX on riscv64 is SiFive Freedom Tools. But it doesn't support Raspberry Pi OS (64-bit Debian). (2) So we used Debian gcc-riscv64-unknown-elf instead. Which shows the missing libm error that Ken described. (3) We're trying an alternative toolchain: xPack GNU RISC-V Embedded GCC. Which might fix the libm problem, but we're not sure if it's supported for NuttX. Wonder if anyone has tried building riscv64 NuttX on Raspberry Pi OS / Arm64 Linux? More details below. Thanks! https://lupyuen.github.io/articles/riscv#appendix-xpack-gnu-risc-v-embedded-gcc-toolchain-for-64-bit-risc-v https://lupyuen.github.io/articles/release#appendix-missing-mathh Lup On Mon, Sep 18, 2023 at 4:15 AM wrote: > On 2023-09-17 12:47, Petro Karashchenko wrote: > > Hi, > > > > What kind of RISC-V toolchain are you using? > > Raspian:RasPi4:~/RISCV/NuttX/apps >>> apt search riscv64-unknown > Sorting... Done > Full Text Search... Done > binutils-riscv64-unknown-elf/oldstable,now 2.32.2020.04+dfsg-2 arm64 > [installed] >GNU assembler, linker and binary utilities for RISC-V processors > > gcc-riscv64-unknown-elf/oldstable,now 8.3.0.2019.08+dfsg-1 arm64 > [installed] >GCC compiler for embedded RISC-V chips > > picolibc-riscv64-unknown-elf/oldstable,oldstable,now 1.5.1-2 all > [installed] >Smaller embedded C library for RISC-V development > > So just `sudo apt-get install ...` of the above. > > > Please try to remove "CFLAGS += -lm " and feedback if that helps. > > No change. > > The problem is not that I am trying to use some released libm library > but that the NuttX nuttx/libs/libm/libm.a is not being linked into the > scheme binary file. > > I have not used other than trivial makefiles in a couple of decades, > never used `make menuconfig`, which allows one to specify many > non-bootable systems, and so have little clue how to specify linking the > NuttX libm into the scheme executable or alternately getting nuttx to > dynamically load the libm library. > > Note that there is no file 'kconfig-language.txt' in the NuttX tools > repository. > > I am kinda stuck. Thanks for any help! > -KenD > >
Re: riscv64 libm link question
On 2023-09-17 12:47, Petro Karashchenko wrote: Hi, What kind of RISC-V toolchain are you using? Raspian:RasPi4:~/RISCV/NuttX/apps >>> apt search riscv64-unknown Sorting... Done Full Text Search... Done binutils-riscv64-unknown-elf/oldstable,now 2.32.2020.04+dfsg-2 arm64 [installed] GNU assembler, linker and binary utilities for RISC-V processors gcc-riscv64-unknown-elf/oldstable,now 8.3.0.2019.08+dfsg-1 arm64 [installed] GCC compiler for embedded RISC-V chips picolibc-riscv64-unknown-elf/oldstable,oldstable,now 1.5.1-2 all [installed] Smaller embedded C library for RISC-V development So just `sudo apt-get install ...` of the above. Please try to remove "CFLAGS += -lm " and feedback if that helps. No change. The problem is not that I am trying to use some released libm library but that the NuttX nuttx/libs/libm/libm.a is not being linked into the scheme binary file. I have not used other than trivial makefiles in a couple of decades, never used `make menuconfig`, which allows one to specify many non-bootable systems, and so have little clue how to specify linking the NuttX libm into the scheme executable or alternately getting nuttx to dynamically load the libm library. Note that there is no file 'kconfig-language.txt' in the NuttX tools repository. I am kinda stuck. Thanks for any help! -KenD
Re: Enforcing C++ compatibility with C code in CI/CD
Since C++ most likely will never be used in the kernel I see that compatibility border should stay in the "include" folder in nuttx repo. The nuttx-apps headers should be C++ compatible as we can mix things at application level.
Re: riscv64 libm link question
Hi, What kind of RISC-V toolchain are you using? I recall that the RISC-V toolchain provided by Ubuntu is built without libm support. Also I noticed that you have "CFLAGS += -lm " in Make.defs and with CONFIG_LIBM=y that should be removed I think as you try to rebuild math from NuttX sources. Please try to remove "CFLAGS += -lm " and feedback if that helps. Best regards, Petro нд, 17 вер. 2023 р. о 19:34 пише: > Please forgive the noob question. > > I am porting a Scheme interpreter to riscv64 NuttX as > apps/interpreters/umb-scheme/ but the binary fails to link in libm > functions. > > I could use some help in this. > > Specifically, building on Raspberry Pi 4 Raspian 64 bit: > > Raspian:RasPi4:~/RISCV/NuttX/apps/bin >>> riscv64-linux-gnu-gcc-nm -u > scheme > U acos > U asin > U atan > U atan2 > U ceil > U cos > U exp > U floor > U log > U pow > U sin > U sqrt > U tan > > I am following the Pine64 Start64 recipe, which does yield a bootable > NuttX on VisionFive 2 SoC: > > > > https://nuttx.apache.org/docs/latest/platforms/risc-v/jh7110/boards/star64/index.html > > My nuttx/.config file contains: > > CONFIG_LIBM=y > CONFIG_ARCH_FLOAT_H=y > > The interpreter local make/config files are attached. They should be > unsurprising. > > Perhaps some kind person can help me out with the proper build flags. > > Thanks much! > -KenD [Ken (dot) Dickey (at) Whidbey (dot) COM] > > > > > >
riscv64 libm link question
Please forgive the noob question.
I am porting a Scheme interpreter to riscv64 NuttX as
apps/interpreters/umb-scheme/ but the binary fails to link in libm
functions.
I could use some help in this.
Specifically, building on Raspberry Pi 4 Raspian 64 bit:
Raspian:RasPi4:~/RISCV/NuttX/apps/bin >>> riscv64-linux-gnu-gcc-nm -u
scheme
U acos
U asin
U atan
U atan2
U ceil
U cos
U exp
U floor
U log
U pow
U sin
U sqrt
U tan
I am following the Pine64 Start64 recipe, which does yield a bootable
NuttX on VisionFive 2 SoC:
https://nuttx.apache.org/docs/latest/platforms/risc-v/jh7110/boards/star64/index.html
My nuttx/.config file contains:
CONFIG_LIBM=y
CONFIG_ARCH_FLOAT_H=y
The interpreter local make/config files are attached. They should be
unsurprising.
Perhaps some kind person can help me out with the proper build flags.
Thanks much!
-KenD [Ken (dot) Dickey (at) Whidbey (dot) COM]
config INTERPRETERS_UMB_SCHEME
tristate "UMB-Scheme R4RS Scheme interpreter"
default y
---help---
Enable the UMB-Scheme `scheme` interpreter
- Be sure to set CONFIG_LIBM=y in your .config file
- Be sure to set CONFIG_ARCH_SETJMP_H=y in your .config file
#if INTERPRETERS_UMB_SCHEME
#
#config INTERPRETERS_UMB_SCHEME_PRIORITY
#int "UMB-Scheme task priority"
#default 100
#
#config INTERPRETERS_UMB_SCHEME_STACKSIZE
#int "UMB-Scheme stack size"
# default 4096
#
#endif# Makefile for the UMB Scheme interpreter.
include $(APPDIR)/Make.defs
# UMB-Scheme built-in application info
PROGNAME = scheme
PRIORITY = 100
#$(INTERPRETERS_UMB_SCHEME_PRIORITY)
STACKSIZE = 4096
#$(INTERPRETERS_UMB_SCHEME_STACKSIZE)
MODULE= $(INTERPRETERS_UMB_SCHEME)
# UMB-Scheme components
CSRCS = object.c primitive.c debug.c
CSRCS += io.c compiler.c eval.c architecture.c number.c
CSRCS += fixnum.c bignum.c rational.c real.c complex.c
MAINSRC = steering.c
###??### LDLIBS += ${NUTTX_PATH}/libs
include $(APPDIR)/Application.mk
### E O F ###
# ?? How to turn off -Wstrict-prototypes ??
ifneq ($(CONFIG_INTERPRETERS_UMB_SCHEME),)
CONFIGURED_APPS += $(APPDIR)/interpreters/umb-scheme
CFLAGS += -lm
endif
Re: ESP32S3 partition sizes?
Hi,
That part of the documentation looks like it is specific to esp32 only
(not esp32s or esp32c). This info applies to all the esp32 variants (s,
c, h, etc). That's why I was wondering where this should end up...
There doesn't seem to be a place for esp32 non-variant-specific
documentation.
I think I may end up having to make it part of the bootloader readme and
then put a brief blurb ("for more info or to change partition sizes,
etc") on each of the 3 variant documentation pages pointing to it. If
anyone has a better idea let me know.
Thanks,
-m
On 9/17/2023 8:39 AM, Tomek CEDRO wrote:
Thanks Mike for willing to contribute your discoveries :-)
I guess you can put this info into ESP32 documentation as there is a
section dedicated for bootloader and partitioning?
https://nuttx.apache.org/docs/latest/platforms/xtensa/esp32/index.html
Also there is FAQ section that may fit the need :-)
Re: ESP32S3 partition sizes?
On Sun, Sep 17, 2023 at 2:18 PM Mike Moretti wrote: > (..) > I would like to contribute documentation for this. Where, where would > this documentation belong? This is definitely not specific to esp32s3 > (but applies to all esp32 variants) and I don't even know if it's > specific to esp32? Is this bootloader used for stm32 and other platforms? Thanks Mike for willing to contribute your discoveries :-) I guess you can put this info into ESP32 documentation as there is a section dedicated for bootloader and partitioning? https://nuttx.apache.org/docs/latest/platforms/xtensa/esp32/index.html Also there is FAQ section that may fit the need :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: ESP32S3 partition sizes?
Hi, I found some info in the NuttX bootloader readme in the github repo. Apparently the default non-mcuboot partition table is setup as one 1M partition. This is why my build was failing to boot (as it was 1.5M). I was able to modify the partition size through sheer luck, as nothing is documented very well. I read the readme and then poked around and looked at files, and then it wasn't until I looked at the build_idfboot.sh script that I found what files were being used by default that specified flash size and the partition table, and the figured out that I needed to either modify those (or make separate custom files) to make this happen. I would like to contribute documentation for this. Where, where would this documentation belong? This is definitely not specific to esp32s3 (but applies to all esp32 variants) and I don't even know if it's specific to esp32? Is this bootloader used for stm32 and other platforms? -m On 9/16/2023 10:11 PM, Tiago Medicci Serrano wrote: Hi Mike, You should have no problems flashing 1.5MB (megabytes, I'm supposing) into an ESP32-S3. Probably your problem is not related to that... Could you please your error message? Best regards, Em sex., 15 de set. de 2023 às 16:12, Mike Moretti escreveu:
