Re: AVR32 on NuttX
Dear Alan, Dear Gregory, Greetings! Hello Kevin and Zou Boan! Many thanks for your suggestions. I will write in detail in a bit but before, I was too excited about Alan's suggestion. > Other option could be extend the CMake support to AVR32 boards. I quickly glanced through boards/arm/stm32 to see how the CMake files work. I put in place the CMakeLists files (similar to stm32f103, Blue Pill) for avr32dev1. I then ran cmake seeking help from the instructions here [1]. It initially asked me to pip install kconfiglib. Here's the volley I had with the Cygwin terminal. raman@foobar ~/nuttxspace/nuttx $ cmake -B build -DBOARD_CONFIG=avr32dev1:nsh -GNinja CMake Error at CMakeLists.txt:82 (message): Kconfig environment depends on kconfiglib, Please install: $ pip install kconfiglib -- Configuring incomplete, errors occurred! raman@foobar ~/nuttxspace/nuttx $ pip install kconfiglib Collecting kconfiglib Using cached kconfiglib-14.1.0-py2.py3-none-any.whl (145 kB) Installing collected packages: kconfiglib Successfully installed kconfiglib-14.1.0 Post this, I ran into another CMake error: raman@foobar ~/nuttxspace/nuttx $ cmake -B build -DBOARD_CONFIG=avr32dev1:nsh -GNinja -- Initializing NuttX CMake Warning at CMakeLists.txt:348 (message): Kconfig Configuration Error: C:\Users\raman\anaconda3\Scripts\olddefconfig: arch/Kconfig:252: '/home/raman/nuttxspace/nuttx/build/arch/dummy/Kconfig' not found (in 'source "$BINDIR/arch/dummy/Kconfig"'). Check that environment variables are set correctly (e.g. $srctree, which is unset or blank). Also note that unset environment variables expand to the empty string. CMake Error at CMakeLists.txt:353 (message): Failed to initialize Kconfig configuration: -- Configuring incomplete, errors occurred! I initially wanted to check if the case is the same for other targets. CMake throws the same response for stm32f103-minimum too. I checked what the programs olddefconfig and defconfig did. Simply invoking the programs olddefconfig.exe (OR defconfig) echo this for a response: raman@foobar ~/nuttxspace/nuttx $ oldconfig Kconfig:10: warning: APPSDIR has 'option env="APPSDIR"', but the environment variable APPSDIR is not set Kconfig:14: warning: APPSBINDIR has 'option env="APPSBINDIR"', but the environment variable APPSBINDIR is not set Kconfig:22: warning: BINDIR has 'option env="BINDIR"', but the environment variable BINDIR is not set Kconfig:278: warning: the 'modules' option is not supported. Let me know if this is a problem for you, as it wouldn't be that hard to implement. Note that modules are supported -- Kconfiglib just assumes the sy mbol name MODULES, like older versions of the C implementation did when 'option modules' wasn't used. C:\Users\raman\anaconda3\Scripts\oldconfig: arch/Kconfig:252: '$BINDIR/arch/dummy/Kconfig' not found (in 'source "$BINDIR/arch/dummy/Kconfig"'). Check that environment variables are set correctly (e.g. $srctree , which is unset or blank). Also note that unset environment variables expand to the empty string. Perhaps I am missing yet another terminal configuration? I will write back in a couple of hours with the results of the minicom session with AVR32DEV1. Many thanks. References: [1]: https://nuttx.apache.org/docs/latest/quickstart/compiling_cmake.html On Sun, 19 Nov 2023 at 04:03, Alan C. Assis wrote: > Hi Raman, > > I'm CC Kevin Liu, he integrated NuttX into Microchip Studio in the > past (although I thing he used the "make export" and imported the > library on it). > > On 11/18/23, Raman Gopalan wrote: > > Dear Alan, Greetings! > > > > Many thanks for your message. I am sorry about the slight delay in > > response. > > > > No problem, great to see you are trying to find a way! > > >> Thank you for reviving this discussing (I'm CC NuttX mailing list > >> because it could interest one person or two). > > > > Perfect! > > > >> $ ./tools/configure.sh avr32dev1:nsh > > > > I encountered the same problems you mention with the GNU/Linux build > > last week. I remember checking the Generate Debug Symbols options too > > on menuconfig. The avr32-gcc for GNU/Linux was able to generate the > > elf file. No problem at all. > > > > Maybe we will need a more up to date avr32-gcc version to compile > without those issues. > > >>> I wasn't sure if I had missed any references while mapping the > >>> source files. I can't trigger a breakpoint yet with this approach. > > > > I took the elf file onto the Windows machine to see if I can debug the > > code using Microchip Studio. File -> Open -> Open Object File For > > Debugging. Post the loading of the elf, I had to map the location of > > the build files. > > > > Some years ago I used ASF (Atmel Studio Framework) to compile a code > with debug symbols that I was able to debug on Linux (oposite > direction you want), but to get the ELF binary working on Linux I had > to replace the "C:\blablabla\AtmelStudioFramework\path" with something > like
Re: [Article] NuttX on Ox64 BL808 RISC-V SBC: Sv39 Memory Management Unit
On Sun, Nov 19, 2023 at 12:42 AM Lee, Lup Yuen wrote: > Memory Management Unit (MMU) is the hardware inside our Single-Board > Computer (SBC) that implements Memory Protection and Virtual Memory. > (..) > Check out the article: https://lupyuen.codeberg.page/articles/mmu.html Amazing read Lup.. as always! Thank You and Congratulations! :-) -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
[Article] NuttX on Ox64 BL808 RISC-V SBC: Sv39 Memory Management Unit
Memory Management Unit (MMU) is the hardware inside our Single-Board Computer (SBC) that implements Memory Protection and Virtual Memory. Sv39 is the RISC-V MMU inside the Pine64 Ox64 SBC, based on Bouffalo Lab BL808 SoC. In this article, we boot NuttX on Ox64 SBC to find out how Sv39 MMU works with: (1) Memory Protection (for our Kernel) (2) Virtual Memory (for the Applications) As we record everything that happens when NuttX configures the Sv39 MMU. Check out the article: https://lupyuen.codeberg.page/articles/mmu.html Lup
Re: AVR32 on NuttX
AFAIK, the Cygwin build using a windows native tool chain has been broken for years. There is no advice anyone can give that that is just going to make it work. It is broken and no one has interest in fixing that which they have broken. People make many changes to the build system but never test on Cygwin with a native toolchain. The basic Cygwin environment is a GNU/POSIX environment equivalent to the GNU/Linux environment. It is slower for two reasons: The fork() emulation under Cygwin is notoriously slow and the run-time virus detection interferes with every compilation. Tuning things and turning off virus checks can greatly improve performance. We have had 7 second Cygwin builds in the distant past. The other issue is the toolchain that you use. If you build a GCC toolchain from scratch under Cygwin, then the build probably still works. That is a pure POSIX environment. But most people want to use a Windows native toolchain like the one that comes with Microchip Studio. That does not work in a POSIX environment and the complexity skyrockets: * The configuration has to be changed to specify that you use a Windows native tool chain (as reflected by the build WINTOOL setting). * All of the build paths are standard POSIX paths like /cygdrive/c/a/b/c. All of the paths provided as input to the Windows native tool have to be converted to Windows paths like C:\a\b\c * Similarly, all paths generated by the Windows native toolchain will be such Windows paths and must be converted to POSIX paths to be used by the build system. * In order for the back slash to be usable by make system or passed on as a command line argument, it has to be quoted in some fashion, perhaps like "C:\a\b\c" * When a quoted path is passed on the command line, it gets de-quoted. That is, if you passed "C:\a\b\c", it will be received like C:\a\b\c. It has been modified. If you tried using it again, it becomes C:abc which is useless. This was all carefully balanced and used for many years. NuttX was developed primarily on Cygwin with a native tool chain. But that has been thrown in the shitter. At this point, it is not not worth resurrecting it. Some one will just break it again since it does not get testing by the CI.
Re: AVR32 on NuttX
Hi Raman,
I'm CC Kevin Liu, he integrated NuttX into Microchip Studio in the
past (although I thing he used the "make export" and imported the
library on it).
On 11/18/23, Raman Gopalan wrote:
> Dear Alan, Greetings!
>
> Many thanks for your message. I am sorry about the slight delay in
> response.
>
No problem, great to see you are trying to find a way!
>> Thank you for reviving this discussing (I'm CC NuttX mailing list
>> because it could interest one person or two).
>
> Perfect!
>
>> $ ./tools/configure.sh avr32dev1:nsh
>
> I encountered the same problems you mention with the GNU/Linux build
> last week. I remember checking the Generate Debug Symbols options too
> on menuconfig. The avr32-gcc for GNU/Linux was able to generate the
> elf file. No problem at all.
>
Maybe we will need a more up to date avr32-gcc version to compile
without those issues.
>>> I wasn't sure if I had missed any references while mapping the
>>> source files. I can't trigger a breakpoint yet with this approach.
>
> I took the elf file onto the Windows machine to see if I can debug the
> code using Microchip Studio. File -> Open -> Open Object File For
> Debugging. Post the loading of the elf, I had to map the location of
> the build files.
>
Some years ago I used ASF (Atmel Studio Framework) to compile a code
with debug symbols that I was able to debug on Linux (oposite
direction you want), but to get the ELF binary working on Linux I had
to replace the "C:\blablabla\AtmelStudioFramework\path" with something
like "/home/alan/longpathmatchingwindowspath/" and put the source
files on that long directory name. Then GDB was able to find it.
Maybe you need to do something similar to let the GDB on Windows IDE
to find the source files.
> I replicated the NuttX codebase on Windows and for every Linux (NuttX
> C file) path the elf reported, I replaced it with the local Windows
> path to check if the debug session works. But still, no luck. I think
> this still has something to do with the forward and backward path
> slashes.
>
Did you match the path base directory lenght? If your build path on
Linux had 45 characters, the equivalent path on Windows needs to have
45 chars as well, otherwise it will fail.
>> I don't use Windows, but yes I think the issue is related to
>> Unix/Windows directories delimitator: "\" vs "/", etc. I think
>> there is some configuration on Cygwin to improve Linux/Unix
>> compatibility.
>
> Understand, Alan.
>
> I did explore a bit further. First, I invoked make with V=1. This was
> very helpful. I tried to check where the build process broke. The
> build doesn't proceed after the invocation of mkwindeps.sh.
> Specifically, this line:
>
> ${MKDEPS} ${DEBUG} --winpath $* > ${TMPFILE} || { echo "# ERROR:
> mkdeps.exe failed"; exit 1; }
>
> It writes "mkdeps.exe failed" into the TMP file. I configured the
> build with the Cygwin flag:
>
Maybe someone with more Windows/Cygwin background could help!
> $ make distclean
> $ ./tools/configure.sh -c avr32dev1:nsh
>
> My experience with Cygwin is that it is very slow. It takes too long
> to even distclean. Because it took too long, I decided to put this
> approach on the back burner for now.
>
Yes, maybe as an alternative we could try to get WSL or WSL2 working
to build the AVR32 boards.
Other option could be extend the CMake support to AVR32 boards.
> I drew inspiration from your very helpful video tutorial on
> "Code::Blocks IDE integration to compile and debug NuttX". I tried to
> check if I can import NuttX into Microchip Studio post the BSP
> configure.sh invocation.
>
> I waited for a significantly long time (on a reasonably fast work
> machine) before Microchip Studio was able to import the codebase. I
> configured the project to use the "external" Makefile. The build fails
> with the following output.
>
> -- Build started: Project: avr32dev1_nuttx_sample, Configuration: Debug
> AVR --
> Build started.
> Project "avr32dev1_nuttx_sample.cproj" (default targets):
> Target "PreBuildEvent" skipped, due to false condition;
> ('$(PreBuildEvent)'!='') was evaluated as (''!='').
> Target "CoreBuild" in file "C:\Program Files
> (x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project
> "C:\Users\raman\Documents\Atmel
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample.
> cproj" (target "Build" depends on it):
> Task "RunCompilerTask"
> Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
> C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe -C
> "C:\Users\raman\Documents\Atmel
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx" -f
> "Makefile" all
> make: Entering directory 'C:/Users/raman/Documents/Atmel
> Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx'
> C:\Users\raman\Documents\Atmel
> Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Makefile.host(23,1):
> error: C:/Users/raman/Documents/Atmel: No such file or directory
>
Re: AVR32 on NuttX
Dear Alan, Greetings!
Many thanks for your message. I am sorry about the slight delay in
response.
> Thank you for reviving this discussing (I'm CC NuttX mailing list
> because it could interest one person or two).
Perfect!
> $ ./tools/configure.sh avr32dev1:nsh
I encountered the same problems you mention with the GNU/Linux build
last week. I remember checking the Generate Debug Symbols options too
on menuconfig. The avr32-gcc for GNU/Linux was able to generate the
elf file. No problem at all.
>> I wasn't sure if I had missed any references while mapping the
>> source files. I can't trigger a breakpoint yet with this approach.
I took the elf file onto the Windows machine to see if I can debug the
code using Microchip Studio. File -> Open -> Open Object File For
Debugging. Post the loading of the elf, I had to map the location of
the build files.
I replicated the NuttX codebase on Windows and for every Linux (NuttX
C file) path the elf reported, I replaced it with the local Windows
path to check if the debug session works. But still, no luck. I think
this still has something to do with the forward and backward path
slashes.
> I don't use Windows, but yes I think the issue is related to
> Unix/Windows directories delimitator: "\" vs "/", etc. I think
> there is some configuration on Cygwin to improve Linux/Unix
> compatibility.
Understand, Alan.
I did explore a bit further. First, I invoked make with V=1. This was
very helpful. I tried to check where the build process broke. The
build doesn't proceed after the invocation of mkwindeps.sh.
Specifically, this line:
${MKDEPS} ${DEBUG} --winpath $* > ${TMPFILE} || { echo "# ERROR:
mkdeps.exe failed"; exit 1; }
It writes "mkdeps.exe failed" into the TMP file. I configured the
build with the Cygwin flag:
$ make distclean
$ ./tools/configure.sh -c avr32dev1:nsh
My experience with Cygwin is that it is very slow. It takes too long
to even distclean. Because it took too long, I decided to put this
approach on the back burner for now.
I drew inspiration from your very helpful video tutorial on
"Code::Blocks IDE integration to compile and debug NuttX". I tried to
check if I can import NuttX into Microchip Studio post the BSP
configure.sh invocation.
I waited for a significantly long time (on a reasonably fast work
machine) before Microchip Studio was able to import the codebase. I
configured the project to use the "external" Makefile. The build fails
with the following output.
-- Build started: Project: avr32dev1_nuttx_sample, Configuration: Debug
AVR --
Build started.
Project "avr32dev1_nuttx_sample.cproj" (default targets):
Target "PreBuildEvent" skipped, due to false condition;
('$(PreBuildEvent)'!='') was evaluated as (''!='').
Target "CoreBuild" in file "C:\Program Files
(x86)\Atmel\Studio\7.0\Vs\Compiler.targets" from project
"C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample.
cproj" (target "Build" depends on it):
Task "RunCompilerTask"
Shell Utils Path C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils
C:\Program Files (x86)\Atmel\Studio\7.0\shellUtils\make.exe -C
"C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx" -f
"Makefile" all
make: Entering directory 'C:/Users/raman/Documents/Atmel
Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx'
C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Makefile.host(23,1):
error: C:/Users/raman/Documents/Atmel: No such file or directory
C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Makefile.host(23,1):
error:
Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx/tools/../tools/Config.mk:
No such file or directory
make: *** No rule to make target
'Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx/tools/../tools/Config.mk'.
Stop.
C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\tools\Win.mk(36,1):
error: C:\Users\raman\Documents\Atmel: No such file or directory
C:\Users\raman\Documents\Atmel
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\tools\Win.mk(36,1):
error:
Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Make.defs:
No such file or directory
echo CONFIG_VERSION_STRING="0" > .version
echo CONFIG_VERSION_MAJOR=0 >> .version
echo CONFIG_VERSION_MINOR=0 >> .version
echo CONFIG_VERSION_PATCH=0 >> .version
echo CONFIG_VERSION_BUILD="0" >> .version
echo CONFIG_VERSION_STRING="0" > .version
echo CONFIG_VERSION_MAJOR=0 >> .version
echo CONFIG_VERSION_MINOR=0 >> .version
echo CONFIG_VERSION_PATCH=0 >> .version
echo CONFIG_VERSION_BUILD="0" >> .version
make: *** No rule to make target
'Studio\7.0\avr32dev1_nuttx_sample\avr32dev1_nuttx_sample\nuttx\Make.defs'.
Stop.
make: Leaving directory 'C:/Users/raman/Documents/Atmel
Studio/7.0/avr32dev1_nuttx_sample/avr32dev1_nuttx_sample/nuttx'
Done executing task
