Article: NuttX for PinePhone: Blinking the LEDs
This article explains how we run the BASIC Interpreter on NuttX, to experiment with the LEDs and GPIOs on Pine64's PinePhone... https://lupyuen.github.io/articles/pio Lup
imxrt1176 on Nuttx
I want to ask my friends, is there anyone who supports imxrt1176 on Nuttx？At present, there are only imxrt1020, imxrt1050, imxrt1060 and imxrt1064 in the Nuttx code.
Re: imxrt1176 on Nuttx
Hi Prelude, I think imxrt1176 is not available yet, did you get it? Probably the peripherals will be the same. BTW: did you test the W5500? BR, Alan On Wednesday, September 21, 2022, prelude wrote: > I want to ask my friends, is there anyone who supports imxrt1176 on > Nuttx？At present, there are only imxrt1020, imxrt1050, imxrt1060 and > imxrt1064 in the Nuttx code. > > >
FreeBSD: /usr/local prefix (for /usr/local/[include,lib])
Hello world :-) I am slowly getting back to NuttX :-) On FreeBSD all local packages are installed under /usr/local prefix that does not seem to be added by tools/configure (or other) and this results in missing includes build error, for instance: CC: sim/up_x11framebuffer.c sim/up_x11framebuffer.c:29:10: fatal error: 'X11/Xlib.h' file not found #include ^~~~ 1 error generated. gmake[1]: *** [Makefile:260: up_x11framebuffer.o] Error 1 That file is present on the system: % ls -al /usr/local/include/X11/Xlib.h -rw-r--r-- 1 root wheel 99811 1 lip 2021 /usr/local/include/X11/Xlib.h I did a dirty hack some time ago, but I forgot it, and I would like to make things work out of the box after pull :-) What would be the most elegant way to add /usr/local/lib and /usr/local/include or whole /usr/local prefix to search/configuration paths? Any hints welcome :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Issues regarding UART and GPIO with NuttX for ESP32
Hello, I have submitted issues with usage of GPIO and UART drivers with NuttX for ESP32 in the apache/incubator-nuttx git repo. Please find the links to those below GPIO: https://github.com/apache/incubator-nuttx/issues/7152 UART: https://github.com/apache/incubator-nuttx/issues/7150 It would be really nice if someone could help me out on these. I am really looking forward to hearing from someone. Thanks & Regards, Srivamsi Malladi.
malloc, free, strdup and kernel builds
So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build. For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build. The TLDR; is this design question: Do we expect malloc and free to work with the relevant heaps? So for the OS should they be working with the kernel heap and for apps they should be using the user heap? I am trying to work out if the problem is with strdup or with malloc & free. Investigation / background My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years. The system under development uses a protected/kernel build with a memory protection unit. We also have two heaps, one for the OS and one for the app. At some point in the OS lifecycle we have the need to generate copies of strings. These were generated using strdup. At some point in the future these strings were released using free. At a point further in the future the system crashed. After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap. When this was then later allocated and used in user space the system would crash with a memory fault. Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds. It also appears that malloc and free always work with the user heap. I know that our build is a little old but looking at the sources this seems to be the case with the current release. I am struggling to get the protected build working on a F767 board to verify if the problem is still present. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
Re: malloc, free, strdup and kernel builds
This does not seem like a technical issue but rather awkward usage/naming that is prone to misuse. Yes, free() should be called to release the memory allocated by strdup. But applications cannot use the kernel heap and, for reasons of protection, the kernel should not store anything in the user-accessible application heap in Protected mode. In Kernel mode, the application heap may not even be available to OS without switching the address environment. So I think that a clean solution would be to fix the naming, either: (1) rename the stdup used by the OS to kmm_strdup() with allocated memory freed by kmm_free(), or (2) conditionally redefine free() to be kmm_free() in the kernel portion of the build. kmm_free() is already defined as free() in the FLAT build in include/nuttx/kmalloc.h On 9/21/2022 9:59 AM, Mark Stevens wrote: So this post has been triggered by an issue I have just had using strdup in the OS components of a protected mode build. For clarity I will be using the term OS for the kernel part of the build and application/app for the user part of the build. The TLDR; is this design question: Do we expect malloc and free to work with the relevant heaps? So for the OS should they be working with the kernel heap and for apps they should be using the user heap? I am trying to work out if the problem is with strdup or with malloc & free. Investigation / background My understanding of strdup is that any string generated should have its memory released using free, at least that is the way I have been using it for years. The system under development uses a protected/kernel build with a memory protection unit. We also have two heaps, one for the OS and one for the app. At some point in the OS lifecycle we have the need to generate copies of strings. These were generated using strdup. At some point in the future these strings were released using free. At a point further in the future the system crashed. After some tracking it turns out that strdup was allocating memory using the kernel heap (the strings were duplicated in the OS) and then freed in the OS but the memory was being released to the user (Application) heap. When this was then later allocated and used in user space the system would crash with a memory fault. Investigation points to the fact that strdup uses lib_malloc which will call kmm_malloc in OS builds and malloc in app builds. It also appears that malloc and free always work with the user heap. I know that our build is a little old but looking at the sources this seems to be the case with the current release. I am struggling to get the protected build working on a F767 board to verify if the problem is still present. Regards, Mark _ Blog: blog.thepcsite.co.uk Twitter: @nevynuk
