Re: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570
On Fri, Apr 7, 2023 at 9:58 AM Sebastien Lorquet wrote: > Thanks for the notification. > > Your proposal is mostly OK for me, I hope others will send reactions > too. I have just one concern. > > > If I attempt to rephrase the proposal: Starting from a commit in a > future, stm32h7 GPIO definitions will not include speed indications > anymore, and these will have to be added manually in board.h, but ONLY > if the LEGACY_PINMAP is not set? > > > Here is my concern: What will happen if a user (me, probably) builds a > NuttX with this new commit from a full stored defconfig, but does not > regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting > will not be present when building in that case. > > Can we force a config update before starting the build, so the > LEGACY_PINMAP setting will be set to Y automatically in all cases? > > > Also, this has to be documented very clearly, not just the official > release notes for the next release! > > Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a > compile time warning in stm32h7/stm32_gpio.c that in the future, users > are required to update their board.h and once done, disable LEGACY_PINMAP ? > > Sebastien I am okay with this and have substantially the same remarks as Sebastien. We should be careful to document it in the release notes, and I have some (still vague) idea how to help people notice this change (and future breaking changes) if they build from a stored full defconfig (meaning a saved .config): Could we add a Kconfig setting that in some way identifies the version of NuttX with which it was created? The idea is that if you load a full defconfig from an earlier release, you could get a build-time warning about breaking changes that happened since that release. Each time we add a breaking change, we would encode/document it in some kind of file that encodes all such breaking changes (at least starting with the release where this feature is introduced) along with logic what to check for each breaking change... So for an example related to STM32 GPIO pin speeds, you load an old saved full .config and try to build with it, and if the config was created with a NuttX version older than X.Y and the arch is STM32 and STM32xx_USE_LEGACY_PINMAP is not set, then the build would output a warning: "Warning: You may need to update your board.h to specify GPIO pin speeds. See PR #." or something like that. Just an idea to consider... Nathan
Re: running GCC
Do you find any clear obstacle I'd find? I ask from the perspective of people that knows NuttX (not my case). Or are that obstacles completely unknown? What related obstacles where found when trying to compiling another tool, compatible with many Unix-like targets like the ones GCC can run on? El sáb., 8 abr. 2023 16:31, Gregory Nutt escribió: > > > Why not try it and see what obstacles you encounter? > > Maybe just the C pre-processor? Or the linker or assembler from binutils? > > Perhaps you could try a partial build using the NuttX header files > only. If you could a relocatable object with just the NuttX header > files, then you could link that in later. > > >
Re: running GCC
Why not try it and see what obstacles you encounter? Maybe just the C pre-processor? Or the linker or assembler from binutils? Perhaps you could try a partial build using the NuttX header files only. If you could a relocatable object with just the NuttX header files, then you could link that in later.
Re: running GCC
Assuming that you have the resources and you can perform the build for a NuttX target, then there should be no problem. The cross build of the toolchain for the NuttX target is the hard part. Most of the dependencies I list are GCC build dependencies, not run-time dependencies. So depending upon how you do the build, perhaps those are not issues. Why not try it and see what obstacles you encounter? On 4/8/2023 12:45 PM, Victor Suarez Rovere wrote: So isn't GCC POSIX compliant? I mean a static build of gcc executable and nothing more (no make, awk or anything) The only thing that GCC does is read and write files The C library shouldn't be part of the equation since GCC can compile many C libraries Another compiler (besides clang) won't work since I expect C++ So what's the actual difficulty in running a program that just reads and writes files? On Sat, Apr 8, 2023 at 2:47 PM Gregory Nutt wrote: On 4/7/2023 9:02 PM, Victor Suarez Rovere wrote: Hi everyone! Considering that NuttX is POSIX compliant, can gcc or clang be run on NuttX? I was waiting to see if someone who has actually tried this would respond. I haven't tried to build a GCC toolchain on NuttX and can't say that it is impossible, but it certainly would be a big challenge! * *GCC Components*. GCC consists of several components including binutils and several other prerequisite libraries (GMP, MPFR, MPC). A Bash shell and GNU make would need needed too. * *Other dependencies*: awk, GNU make, Perl, Python3, Flex, Bison, and perhaps automake. Maybe gzip, bzip2, and tar if you build from tarballs. Documentation needs Texinfo. And lots of other things that I forgot. * *GDB*. GDB is usually considered to be part of the toolchain too. But it would not be possible to build GDB because it depends on ptrace which not supported by NuttX. * *C Library*. GCC and C-libraries are very intimately entangled. NuttX has its own C libary. I suspect that the integration with GCC and the NuttX C library would be somewhat challenging as well. * *Other Unsupported Interfaces*. Several interfaces that depend on an MMU (fork, full mmap) are not supported and could also be an issue. * FLAT build? Or Kernel build? Each has it own challenges. * *Delivery*. GCC normally comes as several Linux executables and libraries that use several other shared libraries. How would you package and deliver a GCC toolchain on NuttX? Would you build it into the FLASH image or put it into a huge monolithic ELF executable on some mounted volume? Although I cannot say it is impossible, I would not be optimistic starting a GCC port to NuttX. I would think that a smaller, less feature rich C compiler would be a reasonable job.
Re: running GCC
On Sat, 8 Apr 2023 at 14:46, Victor Suarez Rovere wrote: > > So isn't GCC POSIX compliant? I mean a static build of gcc executable and > nothing more (no make, awk or anything) > The only thing that GCC does is read and write files > The C library shouldn't be part of the equation since GCC can compile many > C libraries > Another compiler (besides clang) won't work since I expect C++ > GCC is implemented in c++ too. > So what's the actual difficulty in running a program that just reads and > writes files? > POSIX compliance does not mean that NuttX can run binaries from other POSIX systems like Linux. You have to start with the source code and build gcc for NuttX. That is the difficult part.
Re: running GCC
So isn't GCC POSIX compliant? I mean a static build of gcc executable and nothing more (no make, awk or anything) The only thing that GCC does is read and write files The C library shouldn't be part of the equation since GCC can compile many C libraries Another compiler (besides clang) won't work since I expect C++ So what's the actual difficulty in running a program that just reads and writes files? On Sat, Apr 8, 2023 at 2:47 PM Gregory Nutt wrote: > On 4/7/2023 9:02 PM, Victor Suarez Rovere wrote: > > Hi everyone! > > Considering that NuttX is POSIX compliant, can gcc or clang be run on > NuttX? > > I was waiting to see if someone who has actually tried this would > respond. I haven't tried to build a GCC toolchain on NuttX and can't > say that it is impossible, but it certainly would be a big challenge! > > * *GCC Components*. GCC consists of several components including > binutils and several other prerequisite libraries (GMP, MPFR, MPC). > A Bash shell and GNU make would need needed too. > > * *Other dependencies*: awk, GNU make, Perl, Python3, Flex, Bison, > and perhaps automake. Maybe gzip, bzip2, and tar if you build from > tarballs. Documentation needs Texinfo. And lots of other things > that I forgot. > > * *GDB*. GDB is usually considered to be part of the toolchain too. > But it would not be possible to build GDB because it depends on > ptrace which not supported by NuttX. > > * *C Library*. GCC and C-libraries are very intimately entangled. > NuttX has its own C libary. I suspect that the integration with GCC > and the NuttX C library would be somewhat challenging as well. > > * *Other Unsupported Interfaces*. Several interfaces that depend on > an MMU (fork, full mmap) are not supported and could also be an issue. > > * FLAT build? Or Kernel build? Each has it own challenges. > > * *Delivery*. GCC normally comes as several Linux executables and > libraries that use several other shared libraries. How would you > package and deliver a GCC toolchain on NuttX? Would you build it > into the FLASH image or put it into a huge monolithic ELF executable > on some mounted volume? > > Although I cannot say it is impossible, I would not be optimistic > starting a GCC port to NuttX. I would think that a smaller, less > feature rich C compiler would be a reasonable job. >
Re: running GCC
On 4/7/2023 9:02 PM, Victor Suarez Rovere wrote: Hi everyone! Considering that NuttX is POSIX compliant, can gcc or clang be run on NuttX? I was waiting to see if someone who has actually tried this would respond. I haven't tried to build a GCC toolchain on NuttX and can't say that it is impossible, but it certainly would be a big challenge! * *GCC Components*. GCC consists of several components including binutils and several other prerequisite libraries (GMP, MPFR, MPC). A Bash shell and GNU make would need needed too. * *Other dependencies*: awk, GNU make, Perl, Python3, Flex, Bison, and perhaps automake. Maybe gzip, bzip2, and tar if you build from tarballs. Documentation needs Texinfo. And lots of other things that I forgot. * *GDB*. GDB is usually considered to be part of the toolchain too. But it would not be possible to build GDB because it depends on ptrace which not supported by NuttX. * *C Library*. GCC and C-libraries are very intimately entangled. NuttX has its own C libary. I suspect that the integration with GCC and the NuttX C library would be somewhat challenging as well. * *Other Unsupported Interfaces*. Several interfaces that depend on an MMU (fork, full mmap) are not supported and could also be an issue. * FLAT build? Or Kernel build? Each has it own challenges. * *Delivery*. GCC normally comes as several Linux executables and libraries that use several other shared libraries. How would you package and deliver a GCC toolchain on NuttX? Would you build it into the FLASH image or put it into a huge monolithic ELF executable on some mounted volume? Although I cannot say it is impossible, I would not be optimistic starting a GCC port to NuttX. I would think that a smaller, less feature rich C compiler would be a reasonable job.
