Re: Testing 10.0 Release Branch
Sounds good. Will be testing on some hardware as well when the RC is cut. On Mon, Nov 23, 2020 at 2:20 AM Brennan Ashton wrote: > > I am looking to cut the RC0 early this week. There have been a lot of > bug fixes that have gone in in the last few weeks (almost 60 patched > backported), and I have tested quite a few targets on actual hardware. > > Unless there is a major issue that pops up I would like to cut the RC0 > Tuesday. > > https://github.com/apache/incubator-nuttx/tree/releases/10.0 > https://github.com/apache/incubator-nuttx-apps/tree/releases/10.0 > > --Brennan
RE: Should TASK_NAME_SIZE be changed in most configs?
> Do you think this is due to the I would say so. I agree better debugging out of the box is a good way to go. We have to weigh that against the past goal of: Minimum size image. It was a first impression thing. This was why debug had to be tuned off in all Kconfig. The first question to ask is do we as a group feel still that the size of the canned config built images should be as small as possible to showcase NuttX ability to be small? David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Sunday, November 22, 2020 5:18 PM To: dev@nuttx.apache.org Subject: Should TASK_NAME_SIZE be changed in most configs? While trying the integration of openocd with NuttX it was complaining due to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == 0. Looking at sched/Kconfig the default for this symbol is 31, yet many configs have this set to zero. Do you think this is due to the default having changed at some point or is this done to minimize memory use in all these boards? If the latter, maybe we need to make the default depend on CONFIG_DEFAULT_SMALL and update all configs that do not have this set. Best, Matias
Re: Should TASK_NAME_SIZE be changed in most configs?
I think we need to have a good compromise between features and size. For instance, the default "nsh" demo should be small, basically just the terminal and minimum support to its commands to work, like the PROCFS to get 'free' working. Also keep in mind that for debugging purpose we need to "Suppress Optimization" that also will increase its size. So, I think it could be a good idea to have a predefined config for debug purpose, instead forcing the "nsh" to be debugging enabled ready by default, that will increase its size and send a wrong message for people testing NuttX for the very first time. See the mbedOS for example: https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ They went into 'rabbit's hole' to solve an issue that we don't have yet, but if nobody keep an eye on it soon we will have. BR, Alan On 11/23/20, David Sidrane wrote: >> Do you think this is due to the > > I would say so. > > I agree better debugging out of the box is a good way to go. We have to > weigh that against the past goal of: Minimum size image. It was a first > impression thing. This was why debug had to be tuned off in all Kconfig. > > The first question to ask is do we as a group feel still that the size of > the canned config built images should be as small as possible to showcase > NuttX ability to be small? > > > David > > > -Original Message- > From: Matias N. [mailto:mat...@imap.cc] > Sent: Sunday, November 22, 2020 5:18 PM > To: dev@nuttx.apache.org > Subject: Should TASK_NAME_SIZE be changed in most configs? > > While trying the integration of openocd with NuttX it was complaining due > to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == > 0. Looking at sched/Kconfig the default for this symbol is 31, yet many > configs have this set to zero. Do you think this is due to the default > having changed at some point or is this done to minimize memory use in all > these boards? If the latter, maybe we need to make the default depend on > CONFIG_DEFAULT_SMALL and update all configs that do not have this set. > > Best, > Matias >
Re: Should TASK_NAME_SIZE be changed in most configs?
It has always been the policy to disable debug features in all shipped configurations. They were considered production configurations not debug configurations. Configurations that have debug enable could, perhaps, be named like nsh-debug. On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: I think we need to have a good compromise between features and size. For instance, the default "nsh" demo should be small, basically just the terminal and minimum support to its commands to work, like the PROCFS to get 'free' working. Also keep in mind that for debugging purpose we need to "Suppress Optimization" that also will increase its size. So, I think it could be a good idea to have a predefined config for debug purpose, instead forcing the "nsh" to be debugging enabled ready by default, that will increase its size and send a wrong message for people testing NuttX for the very first time. See the mbedOS for example: https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ They went into 'rabbit's hole' to solve an issue that we don't have yet, but if nobody keep an eye on it soon we will have. BR, Alan On 11/23/20, David Sidrane wrote: Do you think this is due to the I would say so. I agree better debugging out of the box is a good way to go. We have to weigh that against the past goal of: Minimum size image. It was a first impression thing. This was why debug had to be tuned off in all Kconfig. The first question to ask is do we as a group feel still that the size of the canned config built images should be as small as possible to showcase NuttX ability to be small? David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Sunday, November 22, 2020 5:18 PM To: dev@nuttx.apache.org Subject: Should TASK_NAME_SIZE be changed in most configs? While trying the integration of openocd with NuttX it was complaining due to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == 0. Looking at sched/Kconfig the default for this symbol is 31, yet many configs have this set to zero. Do you think this is due to the default having changed at some point or is this done to minimize memory use in all these boards? If the latter, maybe we need to make the default depend on CONFIG_DEFAULT_SMALL and update all configs that do not have this set. Best, Matias
Re: Should TASK_NAME_SIZE be changed in most configs?
Yes, I think nsh-debug will make its intention clear. On 11/23/20, Gregory Nutt wrote: > It has always been the policy to disable debug features in all shipped > configurations. They were considered production configurations not > debug configurations. > > Configurations that have debug enable could, perhaps, be named like > nsh-debug. > > On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: >> I think we need to have a good compromise between features and size. >> >> For instance, the default "nsh" demo should be small, basically just >> the terminal and minimum support to its commands to work, like the >> PROCFS to get 'free' working. >> >> Also keep in mind that for debugging purpose we need to "Suppress >> Optimization" that also will increase its size. >> >> So, I think it could be a good idea to have a predefined config for >> debug purpose, instead forcing the "nsh" to be debugging enabled ready >> by default, that will increase its size and send a wrong message for >> people testing NuttX for the very first time. >> >> See the mbedOS for example: >> >> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ >> >> They went into 'rabbit's hole' to solve an issue that we don't have >> yet, but if nobody keep an eye on it soon we will have. >> >> BR, >> >> Alan >> >> On 11/23/20, David Sidrane wrote: Do you think this is due to the >>> I would say so. >>> >>> I agree better debugging out of the box is a good way to go. We have to >>> weigh that against the past goal of: Minimum size image. It was a first >>> impression thing. This was why debug had to be tuned off in all Kconfig. >>> >>> The first question to ask is do we as a group feel still that the size >>> of >>> the canned config built images should be as small as possible to >>> showcase >>> NuttX ability to be small? >>> >>> >>> David >>> >>> >>> -Original Message- >>> From: Matias N. [mailto:mat...@imap.cc] >>> Sent: Sunday, November 22, 2020 5:18 PM >>> To: dev@nuttx.apache.org >>> Subject: Should TASK_NAME_SIZE be changed in most configs? >>> >>> While trying the integration of openocd with NuttX it was complaining >>> due >>> to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == >>> 0. Looking at sched/Kconfig the default for this symbol is 31, yet many >>> configs have this set to zero. Do you think this is due to the default >>> having changed at some point or is this done to minimize memory use in >>> all >>> these boards? If the latter, maybe we need to make the default depend on >>> CONFIG_DEFAULT_SMALL and update all configs that do not have this set. >>> >>> Best, >>> Matias >>> >
RE: Should TASK_NAME_SIZE be changed in most configs?
Perfect! Let's do this as time permits. -Original Message- From: Alan Carvalho de Assis [mailto:acas...@gmail.com] Sent: Monday, November 23, 2020 5:09 AM To: dev@nuttx.apache.org Subject: Re: Should TASK_NAME_SIZE be changed in most configs? Yes, I think nsh-debug will make its intention clear. On 11/23/20, Gregory Nutt wrote: > It has always been the policy to disable debug features in all shipped > configurations. They were considered production configurations not > debug configurations. > > Configurations that have debug enable could, perhaps, be named like > nsh-debug. > > On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: >> I think we need to have a good compromise between features and size. >> >> For instance, the default "nsh" demo should be small, basically just >> the terminal and minimum support to its commands to work, like the >> PROCFS to get 'free' working. >> >> Also keep in mind that for debugging purpose we need to "Suppress >> Optimization" that also will increase its size. >> >> So, I think it could be a good idea to have a predefined config for >> debug purpose, instead forcing the "nsh" to be debugging enabled ready >> by default, that will increase its size and send a wrong message for >> people testing NuttX for the very first time. >> >> See the mbedOS for example: >> >> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ >> >> They went into 'rabbit's hole' to solve an issue that we don't have >> yet, but if nobody keep an eye on it soon we will have. >> >> BR, >> >> Alan >> >> On 11/23/20, David Sidrane wrote: Do you think this is due to the >>> I would say so. >>> >>> I agree better debugging out of the box is a good way to go. We have to >>> weigh that against the past goal of: Minimum size image. It was a first >>> impression thing. This was why debug had to be tuned off in all Kconfig. >>> >>> The first question to ask is do we as a group feel still that the size >>> of >>> the canned config built images should be as small as possible to >>> showcase >>> NuttX ability to be small? >>> >>> >>> David >>> >>> >>> -Original Message- >>> From: Matias N. [mailto:mat...@imap.cc] >>> Sent: Sunday, November 22, 2020 5:18 PM >>> To: dev@nuttx.apache.org >>> Subject: Should TASK_NAME_SIZE be changed in most configs? >>> >>> While trying the integration of openocd with NuttX it was complaining >>> due >>> to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == >>> 0. Looking at sched/Kconfig the default for this symbol is 31, yet many >>> configs have this set to zero. Do you think this is due to the default >>> having changed at some point or is this done to minimize memory use in >>> all >>> these boards? If the latter, maybe we need to make the default depend on >>> CONFIG_DEFAULT_SMALL and update all configs that do not have this set. >>> >>> Best, >>> Matias >>> >
Re: Should TASK_NAME_SIZE be changed in most configs?
Hi, sorry for mixing up the discussions. Also, maybe I wasn't clear from my last email, what I did was to try my second suggestion about adding symbols to NuttX to store the offsets of the required elements of the tcb. This is what I tried and works. This is much better than being forced to use a specific configuration to get the offsets right or having to rebuild openocd each time. I will polish the approach and open a draft PR to show how it works. I think this could also be applied to register offsets. This way, each architecture can provide the offsets for its register set and have all architectures working reliably with openocd, regardless of any configuration which may affect the offsets. Regarding the original topic, we can leave the configs with NAME == 0 if you think it is better. Regarding adding an extra debug config, I think that we would be adding a lot of configurations and this adds overhead when testing releases and having to keep configs in sync. I think the approach of using kconfig-tweak to quickly enable/disable debug values is better. This is actually already documented. Best, Matias On Mon, Nov 23, 2020, at 10:29, David Sidrane wrote: > Perfect! Let's do this as time permits. > > -Original Message- > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > Sent: Monday, November 23, 2020 5:09 AM > To: dev@nuttx.apache.org > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > Yes, I think nsh-debug will make its intention clear. > > On 11/23/20, Gregory Nutt wrote: > > It has always been the policy to disable debug features in all shipped > > configurations. They were considered production configurations not > > debug configurations. > > > > Configurations that have debug enable could, perhaps, be named like > > nsh-debug. > > > > On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > >> I think we need to have a good compromise between features and size. > >> > >> For instance, the default "nsh" demo should be small, basically just > >> the terminal and minimum support to its commands to work, like the > >> PROCFS to get 'free' working. > >> > >> Also keep in mind that for debugging purpose we need to "Suppress > >> Optimization" that also will increase its size. > >> > >> So, I think it could be a good idea to have a predefined config for > >> debug purpose, instead forcing the "nsh" to be debugging enabled ready > >> by default, that will increase its size and send a wrong message for > >> people testing NuttX for the very first time. > >> > >> See the mbedOS for example: > >> > >> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > >> > >> They went into 'rabbit's hole' to solve an issue that we don't have > >> yet, but if nobody keep an eye on it soon we will have. > >> > >> BR, > >> > >> Alan > >> > >> On 11/23/20, David Sidrane wrote: > Do you think this is due to the > >>> I would say so. > >>> > >>> I agree better debugging out of the box is a good way to go. We have to > >>> weigh that against the past goal of: Minimum size image. It was a first > >>> impression thing. This was why debug had to be tuned off in all Kconfig. > >>> > >>> The first question to ask is do we as a group feel still that the size > >>> of > >>> the canned config built images should be as small as possible to > >>> showcase > >>> NuttX ability to be small? > >>> > >>> > >>> David > >>> > >>> > >>> -Original Message- > >>> From: Matias N. [mailto:mat...@imap.cc] > >>> Sent: Sunday, November 22, 2020 5:18 PM > >>> To: dev@nuttx.apache.org > >>> Subject: Should TASK_NAME_SIZE be changed in most configs? > >>> > >>> While trying the integration of openocd with NuttX it was complaining > >>> due > >>> to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == > >>> 0. Looking at sched/Kconfig the default for this symbol is 31, yet many > >>> configs have this set to zero. Do you think this is due to the default > >>> having changed at some point or is this done to minimize memory use in > >>> all > >>> these boards? If the latter, maybe we need to make the default depend on > >>> CONFIG_DEFAULT_SMALL and update all configs that do not have this set. > >>> > >>> Best, > >>> Matias > >>> > > >
Re: Should TASK_NAME_SIZE be changed in most configs?
I wonder if we could automate that? Instead of separate debug vs production configurations, could not configure.sh/c just create a debug configuration by disabling optimization, enabling symbols, enabling debug features, assertions, basic error and warning output? Of course specialize configurations like a networking configure would need more (like network debug), but changes like that to configure.sh/c would get you 90% there. On 11/23/2020 7:29 AM, David Sidrane wrote: Perfect! Let's do this as time permits. -Original Message- From: Alan Carvalho de Assis [mailto:acas...@gmail.com] Sent: Monday, November 23, 2020 5:09 AM To: dev@nuttx.apache.org Subject: Re: Should TASK_NAME_SIZE be changed in most configs? Yes, I think nsh-debug will make its intention clear. On 11/23/20, Gregory Nutt wrote: It has always been the policy to disable debug features in all shipped configurations. They were considered production configurations not debug configurations. Configurations that have debug enable could, perhaps, be named like nsh-debug. On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: I think we need to have a good compromise between features and size. For instance, the default "nsh" demo should be small, basically just the terminal and minimum support to its commands to work, like the PROCFS to get 'free' working. Also keep in mind that for debugging purpose we need to "Suppress Optimization" that also will increase its size. So, I think it could be a good idea to have a predefined config for debug purpose, instead forcing the "nsh" to be debugging enabled ready by default, that will increase its size and send a wrong message for people testing NuttX for the very first time. See the mbedOS for example: https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ They went into 'rabbit's hole' to solve an issue that we don't have yet, but if nobody keep an eye on it soon we will have. BR, Alan On 11/23/20, David Sidrane wrote: Do you think this is due to the I would say so. I agree better debugging out of the box is a good way to go. We have to weigh that against the past goal of: Minimum size image. It was a first impression thing. This was why debug had to be tuned off in all Kconfig. The first question to ask is do we as a group feel still that the size of the canned config built images should be as small as possible to showcase NuttX ability to be small? David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Sunday, November 22, 2020 5:18 PM To: dev@nuttx.apache.org Subject: Should TASK_NAME_SIZE be changed in most configs? While trying the integration of openocd with NuttX it was complaining due to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == 0. Looking at sched/Kconfig the default for this symbol is 31, yet many configs have this set to zero. Do you think this is due to the default having changed at some point or is this done to minimize memory use in all these boards? If the latter, maybe we need to make the default depend on CONFIG_DEFAULT_SMALL and update all configs that do not have this set. Best, Matias
Re: Should TASK_NAME_SIZE be changed in most configs?
> This is what I tried and works. This is much better than being forced > to use a specific configuration to get the offsets right or having to rebuild > openocd each time. > I will polish the approach and open a draft PR to show how it works. As I said above, you don't have to do that. The OpenOCD support relies on post file hooks to retrieve these information. https://github.com/sony/openocd-nuttx/wiki On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt wrote: > > I wonder if we could automate that? Instead of separate debug vs > production configurations, could not configure.sh/c just create a debug > configuration by disabling optimization, enabling symbols, enabling > debug features, assertions, basic error and warning output? > > Of course specialize configurations like a networking configure would > need more (like network debug), but changes like that to configure.sh/c > would get you 90% there. > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > Perfect! Let's do this as time permits. > > > > -Original Message- > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > Sent: Monday, November 23, 2020 5:09 AM > > To: dev@nuttx.apache.org > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > Yes, I think nsh-debug will make its intention clear. > > > > On 11/23/20, Gregory Nutt wrote: > >> It has always been the policy to disable debug features in all shipped > >> configurations. They were considered production configurations not > >> debug configurations. > >> > >> Configurations that have debug enable could, perhaps, be named like > >> nsh-debug. > >> > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > >>> I think we need to have a good compromise between features and size. > >>> > >>> For instance, the default "nsh" demo should be small, basically just > >>> the terminal and minimum support to its commands to work, like the > >>> PROCFS to get 'free' working. > >>> > >>> Also keep in mind that for debugging purpose we need to "Suppress > >>> Optimization" that also will increase its size. > >>> > >>> So, I think it could be a good idea to have a predefined config for > >>> debug purpose, instead forcing the "nsh" to be debugging enabled ready > >>> by default, that will increase its size and send a wrong message for > >>> people testing NuttX for the very first time. > >>> > >>> See the mbedOS for example: > >>> > >>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > >>> > >>> They went into 'rabbit's hole' to solve an issue that we don't have > >>> yet, but if nobody keep an eye on it soon we will have. > >>> > >>> BR, > >>> > >>> Alan > >>> > >>> On 11/23/20, David Sidrane wrote: > > Do you think this is due to the > I would say so. > > I agree better debugging out of the box is a good way to go. We have to > weigh that against the past goal of: Minimum size image. It was a first > impression thing. This was why debug had to be tuned off in all Kconfig. > > The first question to ask is do we as a group feel still that the size > of > the canned config built images should be as small as possible to > showcase > NuttX ability to be small? > > > David > > > -Original Message- > From: Matias N. [mailto:mat...@imap.cc] > Sent: Sunday, November 22, 2020 5:18 PM > To: dev@nuttx.apache.org > Subject: Should TASK_NAME_SIZE be changed in most configs? > > While trying the integration of openocd with NuttX it was complaining > due > to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == > 0. Looking at sched/Kconfig the default for this symbol is 31, yet many > configs have this set to zero. Do you think this is due to the default > having changed at some point or is this done to minimize memory use in > all > these boards? If the latter, maybe we need to make the default depend on > CONFIG_DEFAULT_SMALL and update all configs that do not have this set. > > Best, > Matias >
Re: Should TASK_NAME_SIZE be changed in most configs?
Our in-house build system has a modified configure.sh that allows #include directives in defconfig files and subsequent entries to override the inherited config vars, like this: ~/nuttx/boards/arm/stm32l4/haltian-example-board/configs/nsh-dbg$ cat defconfig #include "../nsh/defconfig" # CONFIG_BOARD_DEEPSLEEP_SKIP_DEBUG is not set CONFIG_DEBUG_FEATURES=y CONFIG_DEBUG_ASSERTIONS=y If the inherited parent config had CONFIG_BOARD_DEEPSLEEP_SKIP_DEBUG=y, then this turns it off again and enables the two additional debug options. Best Regards, Juha From: Gregory Nutt Sent: Monday, November 23, 2020 5:07 PM To: dev@nuttx.apache.org Subject: Re: Should TASK_NAME_SIZE be changed in most configs? I wonder if we could automate that? Instead of separate debug vs production configurations, could not configure.sh/c just create a debug configuration by disabling optimization, enabling symbols, enabling debug features, assertions, basic error and warning output? Of course specialize configurations like a networking configure would need more (like network debug), but changes like that to configure.sh/c would get you 90% there. On 11/23/2020 7:29 AM, David Sidrane wrote: > Perfect! Let's do this as time permits. > > -Original Message- > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > Sent: Monday, November 23, 2020 5:09 AM > To: dev@nuttx.apache.org > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > Yes, I think nsh-debug will make its intention clear. > > On 11/23/20, Gregory Nutt wrote: >> It has always been the policy to disable debug features in all shipped >> configurations. They were considered production configurations not >> debug configurations. >> >> Configurations that have debug enable could, perhaps, be named like >> nsh-debug. >> >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: >>> I think we need to have a good compromise between features and size. >>> >>> For instance, the default "nsh" demo should be small, basically just >>> the terminal and minimum support to its commands to work, like the >>> PROCFS to get 'free' working. >>> >>> Also keep in mind that for debugging purpose we need to "Suppress >>> Optimization" that also will increase its size. >>> >>> So, I think it could be a good idea to have a predefined config for >>> debug purpose, instead forcing the "nsh" to be debugging enabled ready >>> by default, that will increase its size and send a wrong message for >>> people testing NuttX for the very first time. >>> >>> See the mbedOS for example: >>> >>> https://eur01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fos.mbed.com%2Fblog%2Fentry%2FOptimizing-memory-usage-in-mbed-OS-52%2F&data=04%7C01%7Cjuha.niskanen%40haltian.com%7C4ac8b58ee8c24898b82108d88fc17d77%7C2f7c629267f24cc582be5d187e289ab2%7C1%7C0%7C637417408508276466%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000&sdata=B4B6VcGPTkMPkktHCVV3%2BVLXnSJ%2B%2F8L39tgbRAFrGB0%3D&reserved=0 >>> >>> They went into 'rabbit's hole' to solve an issue that we don't have >>> yet, but if nobody keep an eye on it soon we will have. >>> >>> BR, >>> >>> Alan >>> >>> On 11/23/20, David Sidrane wrote: > Do you think this is due to the I would say so. I agree better debugging out of the box is a good way to go. We have to weigh that against the past goal of: Minimum size image. It was a first impression thing. This was why debug had to be tuned off in all Kconfig. The first question to ask is do we as a group feel still that the size of the canned config built images should be as small as possible to showcase NuttX ability to be small? David -Original Message- From: Matias N. [mailto:mat...@imap.cc] Sent: Sunday, November 22, 2020 5:18 PM To: dev@nuttx.apache.org Subject: Should TASK_NAME_SIZE be changed in most configs? While trying the integration of openocd with NuttX it was complaining due to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE == 0. Looking at sched/Kconfig the default for this symbol is 31, yet many configs have this set to zero. Do you think this is due to the default having changed at some point or is this done to minimize memory use in all these boards? If the latter, maybe we need to make the default depend on CONFIG_DEFAULT_SMALL and update all configs that do not have this set. Best, Matias
iMXRT1064-EVK nshocram linking issue
Hello, My name is Vadim. I am new to NuttX and to the embedded world in general. I am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board using 1060 configuration with changes to flash-ocram.ld and imxrt_flexspi_nor_boot.h. In imxrt_flexspi_nor_boot.h, I changed FLASH_BASE from 0x6000 to 0x7000 . In flash-ocram.ld, I changed: flash (rx) : ORIGIN and LENGTH from 0x6000 and 7M to 0x7000 and 3M → changing origin address alone leads to this error. Everything links with no issue otherwise (even with other changes excluding this one). flashxip (rx) : ORIGIN and LENGTH from 0x6070 and 1M to 0x7030 and 1M I am getting relocation truncated to fit error: make[2]: Entering directory '/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' CC: imxrt_boot.c CC: imxrt_flexspi_nor_boot.c CC: imxrt_flexspi_nor_flash.c CC: imxrt_appinit.c CC: imxrt_bringup.c CC: imxrt_autoleds.c AR (create): libboard.a imxrt_boot.o imxrt_flexspi_nor_boot.o imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o make[2]: Leaving directory '/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' LD: nuttx /usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0): relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4' make[1]: *** [Makefile:172: nuttx] Error 1 make[1]: Leaving directory '/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src' make: *** [tools/Makefile.unix:423: nuttx] Error 2 I was wondering what needs to be done to make it work? Please, let me know. Thank you for your time. Regards, Vadim
Re: Should TASK_NAME_SIZE be changed in most configs?
Ahh, I didn't know what you were refering to by "post file". I understand now. This should really be documented somewhere in our own docs, as I understand this should work with mainline openocd. Maybe this approach could be extended so that the number of tasks states is also obtained and does not have to be matched against openocd config. I'm still trying to find why I'm getting strange output of thread information. While stopped at NSH's cmd_pwd, I get this: ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 in ?? ()\n" >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd (vtbl=0x20001fb0, >argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" If I just stopped randomly I get this: >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x74a0 in up_idle >() at chip/nrf52_idle.c:191\n" >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x237c in g_idletcb >()\n" So for some reason the PC of the active task is not read correctly. On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > This is what I tried and works. This is much better than being forced > > to use a specific configuration to get the offsets right or having to > > rebuild openocd each time. > > I will polish the approach and open a draft PR to show how it works. > > > As I said above, you don't have to do that. The OpenOCD support > relies on post file hooks to retrieve these information. > https://github.com/sony/openocd-nuttx/wiki > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt wrote: > > > > I wonder if we could automate that? Instead of separate debug vs > > production configurations, could not configure.sh/c just create a debug > > configuration by disabling optimization, enabling symbols, enabling > > debug features, assertions, basic error and warning output? > > > > Of course specialize configurations like a networking configure would > > need more (like network debug), but changes like that to configure.sh/c > > would get you 90% there. > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > Perfect! Let's do this as time permits. > > > > > > -Original Message- > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > Sent: Monday, November 23, 2020 5:09 AM > > > To: dev@nuttx.apache.org > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > On 11/23/20, Gregory Nutt wrote: > > >> It has always been the policy to disable debug features in all shipped > > >> configurations. They were considered production configurations not > > >> debug configurations. > > >> > > >> Configurations that have debug enable could, perhaps, be named like > > >> nsh-debug. > > >> > > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > > >>> I think we need to have a good compromise between features and size. > > >>> > > >>> For instance, the default "nsh" demo should be small, basically just > > >>> the terminal and minimum support to its commands to work, like the > > >>> PROCFS to get 'free' working. > > >>> > > >>> Also keep in mind that for debugging purpose we need to "Suppress > > >>> Optimization" that also will increase its size. > > >>> > > >>> So, I think it could be a good idea to have a predefined config for > > >>> debug purpose, instead forcing the "nsh" to be debugging enabled ready > > >>> by default, that will increase its size and send a wrong message for > > >>> people testing NuttX for the very first time. > > >>> > > >>> See the mbedOS for example: > > >>> > > >>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > > >>> > > >>> They went into 'rabbit's hole' to solve an issue that we don't have > > >>> yet, but if nobody keep an eye on it soon we will have. > > >>> > > >>> BR, > > >>> > > >>> Alan > > >>> > > >>> On 11/23/20, David Sidrane wrote: > > > Do you think this is due to the > > I would say so. > > > > I agree better debugging out of the box is a good way to go. We have to > > weigh that against the past goal of: Minimum size image. It was a first > > impression thing. This was why debug had to be tuned off in all > > Kconfig. > > > > The first question to ask is do we as a group feel still that the size > > of > > the canned config built images should be as small as possible to > > showcase > > NuttX ability to be small? > > > > > > David > > > > > > -Original Message- > > From: Matias N. [mailto:mat...@imap.cc] > > Sent: Sunday, November 22, 2020 5:18 PM > > To: dev@nuttx.apache.org > > Subject: Should TASK_NAME_SIZE be changed in most configs? > > > > While trying the integration of openocd with NuttX it was complaining > > due > > to "name" not being defined, which happens when CONFIG_TASK_NAME_SIZE > > == > > 0. Looking at sched/Kconfig the default for this
RE: iMXRT1064-EVK nshocram linking issue
Hi Vadim, I do not recall all the deltas from the 1062 to the 1064. But the 1064 may have other IP changes, and memory map differences You should create a board new directory imxrt1060-evk. And make the changes there. You will need to know what kind of memory is embedded. Hyper flash or QSPI Also start with nsh config as nshocram is more complex. David -Original Message- From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID] Sent: Monday, November 23, 2020 7:56 AM To: dev@nuttx.apache.org Subject: iMXRT1064-EVK nshocram linking issue Hello, My name is Vadim. I am new to NuttX and to the embedded world in general. I am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board using 1060 configuration with changes to flash-ocram.ld and imxrt_flexspi_nor_boot.h. In imxrt_flexspi_nor_boot.h, I changed FLASH_BASE from 0x6000 to 0x7000 . In flash-ocram.ld, I changed: flash (rx) : ORIGIN and LENGTH from 0x6000 and 7M to 0x7000 and 3M → changing origin address alone leads to this error. Everything links with no issue otherwise (even with other changes excluding this one). flashxip (rx) : ORIGIN and LENGTH from 0x6070 and 1M to 0x7030 and 1M I am getting relocation truncated to fit error: make[2]: Entering directory '/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' CC: imxrt_boot.c CC: imxrt_flexspi_nor_boot.c CC: imxrt_flexspi_nor_flash.c CC: imxrt_appinit.c CC: imxrt_bringup.c CC: imxrt_autoleds.c AR (create): libboard.a imxrt_boot.o imxrt_flexspi_nor_boot.o imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o make[2]: Leaving directory '/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' LD: nuttx /usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0): relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4' make[1]: *** [Makefile:172: nuttx] Error 1 make[1]: Leaving directory '/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src' make: *** [tools/Makefile.unix:423: nuttx] Error 2 I was wondering what needs to be done to make it work? Please, let me know. Thank you for your time. Regards, Vadim
Re: Should TASK_NAME_SIZE be changed in most configs?
Can you see that NuttX was detected and the offsets are correct from OpenOCD? Do you have this in your OpenOCD config file: $_TARGETNAME configure -rtos nuttx I do this with an STM32F4 source [find target/stm32f4x.cfg] $_TARGETNAME configure -rtos nuttx On Mon, Nov 23, 2020 at 4:00 PM Matias N. wrote: > > Ahh, I didn't know what you were refering to by "post file". I understand now. > This should really be documented somewhere in our own docs, as I understand > this should work with mainline openocd. > > Maybe this approach could be extended so that the number of tasks states is > also > obtained and does not have to be matched against openocd config. > > I'm still trying to find why I'm getting strange output of thread > information. While stopped > at NSH's cmd_pwd, I get this: > > ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 in ?? > ()\n" > > >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd > >(vtbl=0x20001fb0, argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" > > > If I just stopped randomly I get this: > > >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x74a0 in > >up_idle () at chip/nrf52_idle.c:191\n" > > >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x237c in g_idletcb > >()\n" > > > So for some reason the PC of the active task is not read correctly. > > On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > > This is what I tried and works. This is much better than being forced > > > to use a specific configuration to get the offsets right or having to > > > rebuild openocd each time. > > > I will polish the approach and open a draft PR to show how it works. > > > > > > As I said above, you don't have to do that. The OpenOCD support > > relies on post file hooks to retrieve these information. > > https://github.com/sony/openocd-nuttx/wiki > > > > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt wrote: > > > > > > I wonder if we could automate that? Instead of separate debug vs > > > production configurations, could not configure.sh/c just create a debug > > > configuration by disabling optimization, enabling symbols, enabling > > > debug features, assertions, basic error and warning output? > > > > > > Of course specialize configurations like a networking configure would > > > need more (like network debug), but changes like that to configure.sh/c > > > would get you 90% there. > > > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > > Perfect! Let's do this as time permits. > > > > > > > > -Original Message- > > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > > Sent: Monday, November 23, 2020 5:09 AM > > > > To: dev@nuttx.apache.org > > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > > > On 11/23/20, Gregory Nutt wrote: > > > >> It has always been the policy to disable debug features in all shipped > > > >> configurations. They were considered production configurations not > > > >> debug configurations. > > > >> > > > >> Configurations that have debug enable could, perhaps, be named like > > > >> nsh-debug. > > > >> > > > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > > > >>> I think we need to have a good compromise between features and size. > > > >>> > > > >>> For instance, the default "nsh" demo should be small, basically just > > > >>> the terminal and minimum support to its commands to work, like the > > > >>> PROCFS to get 'free' working. > > > >>> > > > >>> Also keep in mind that for debugging purpose we need to "Suppress > > > >>> Optimization" that also will increase its size. > > > >>> > > > >>> So, I think it could be a good idea to have a predefined config for > > > >>> debug purpose, instead forcing the "nsh" to be debugging enabled ready > > > >>> by default, that will increase its size and send a wrong message for > > > >>> people testing NuttX for the very first time. > > > >>> > > > >>> See the mbedOS for example: > > > >>> > > > >>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > > > >>> > > > >>> They went into 'rabbit's hole' to solve an issue that we don't have > > > >>> yet, but if nobody keep an eye on it soon we will have. > > > >>> > > > >>> BR, > > > >>> > > > >>> Alan > > > >>> > > > >>> On 11/23/20, David Sidrane wrote: > > > > Do you think this is due to the > > > I would say so. > > > > > > I agree better debugging out of the box is a good way to go. We have > > > to > > > weigh that against the past goal of: Minimum size image. It was a > > > first > > > impression thing. This was why debug had to be tuned off in all > > > Kconfig. > > > > > > The first question to ask is do we as a group feel still that the > > > size > > > of > > > the canned config built images should be as small as possible to > > > showcase > > > NuttX abil
Re: Should TASK_NAME_SIZE be changed in most configs?
Nevermind, I thought I needed to correct register offsets and I only messed them up. I added the commands to my gdb startup and now works as expected. Maybe we could do the same to pass register addresses for other architectures and to set the array of state names? On Mon, Nov 23, 2020, at 14:12, Abdelatif Guettouche wrote: > Can you see that NuttX was detected and the offsets are correct from OpenOCD? > Do you have this in your OpenOCD config file: $_TARGETNAME configure -rtos > nuttx > > I do this with an STM32F4 > > source [find target/stm32f4x.cfg] > > $_TARGETNAME configure -rtos nuttx > > On Mon, Nov 23, 2020 at 4:00 PM Matias N. wrote: > > > > Ahh, I didn't know what you were refering to by "post file". I understand > > now. > > This should really be documented somewhere in our own docs, as I understand > > this should work with mainline openocd. > > > > Maybe this approach could be extended so that the number of tasks states is > > also > > obtained and does not have to be matched against openocd config. > > > > I'm still trying to find why I'm getting strange output of thread > > information. While stopped > > at NSH's cmd_pwd, I get this: > > > > ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 in ?? > > ()\n" > > > > >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd > > >(vtbl=0x20001fb0, argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" > > > > > > If I just stopped randomly I get this: > > > > >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x74a0 in > > >up_idle () at chip/nrf52_idle.c:191\n" > > > > >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x237c in > > >g_idletcb ()\n" > > > > > > So for some reason the PC of the active task is not read correctly. > > > > On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > > > This is what I tried and works. This is much better than being forced > > > > to use a specific configuration to get the offsets right or having to > > > > rebuild openocd each time. > > > > I will polish the approach and open a draft PR to show how it works. > > > > > > > > > As I said above, you don't have to do that. The OpenOCD support > > > relies on post file hooks to retrieve these information. > > > https://github.com/sony/openocd-nuttx/wiki > > > > > > > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt wrote: > > > > > > > > I wonder if we could automate that? Instead of separate debug vs > > > > production configurations, could not configure.sh/c just create a debug > > > > configuration by disabling optimization, enabling symbols, enabling > > > > debug features, assertions, basic error and warning output? > > > > > > > > Of course specialize configurations like a networking configure would > > > > need more (like network debug), but changes like that to configure.sh/c > > > > would get you 90% there. > > > > > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > > > Perfect! Let's do this as time permits. > > > > > > > > > > -Original Message- > > > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > > > Sent: Monday, November 23, 2020 5:09 AM > > > > > To: dev@nuttx.apache.org > > > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > > > > > On 11/23/20, Gregory Nutt wrote: > > > > >> It has always been the policy to disable debug features in all > > > > >> shipped > > > > >> configurations. They were considered production configurations not > > > > >> debug configurations. > > > > >> > > > > >> Configurations that have debug enable could, perhaps, be named like > > > > >> nsh-debug. > > > > >> > > > > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > > > > >>> I think we need to have a good compromise between features and size. > > > > >>> > > > > >>> For instance, the default "nsh" demo should be small, basically just > > > > >>> the terminal and minimum support to its commands to work, like the > > > > >>> PROCFS to get 'free' working. > > > > >>> > > > > >>> Also keep in mind that for debugging purpose we need to "Suppress > > > > >>> Optimization" that also will increase its size. > > > > >>> > > > > >>> So, I think it could be a good idea to have a predefined config for > > > > >>> debug purpose, instead forcing the "nsh" to be debugging enabled > > > > >>> ready > > > > >>> by default, that will increase its size and send a wrong message for > > > > >>> people testing NuttX for the very first time. > > > > >>> > > > > >>> See the mbedOS for example: > > > > >>> > > > > >>> https://os.mbed.com/blog/entry/Optimizing-memory-usage-in-mbed-OS-52/ > > > > >>> > > > > >>> They went into 'rabbit's hole' to solve an issue that we don't have > > > > >>> yet, but if nobody keep an eye on it soon we will have. > > > > >>> > > > > >>> BR, > > > > >>> > > > > >>> Alan > > > > >>> > > > > >>> On 11/23/20, David Sidrane wrote: > > > > > Do you thi
Re: Should TASK_NAME_SIZE be changed in most configs?
The state names is an enumeration from the NuttX side. I'm not sure if we can use the same technique to retrieve it. When adding the Xtensa/ESP32 stack info, I did some re-organisation which should ease adding a new architecture. But that code will need to wait for the next release before it will go to Espressif's fork in Github (maybe a few days). On Mon, Nov 23, 2020 at 4:54 PM Matias N. wrote: > > Nevermind, I thought I needed to correct register offsets and I only messed > them up. > I added the commands to my gdb startup and now works as expected. Maybe we > could do the same > to pass register addresses for other architectures and to set the array of > state names? > > On Mon, Nov 23, 2020, at 14:12, Abdelatif Guettouche wrote: > > Can you see that NuttX was detected and the offsets are correct from > > OpenOCD? > > Do you have this in your OpenOCD config file: $_TARGETNAME configure -rtos > > nuttx > > > > I do this with an STM32F4 > > > > source [find target/stm32f4x.cfg] > > > > $_TARGETNAME configure -rtos nuttx > > > > On Mon, Nov 23, 2020 at 4:00 PM Matias N. wrote: > > > > > > Ahh, I didn't know what you were refering to by "post file". I understand > > > now. > > > This should really be documented somewhere in our own docs, as I > > > understand > > > this should work with mainline openocd. > > > > > > Maybe this approach could be extended so that the number of tasks states > > > is also > > > obtained and does not have to be matched against openocd config. > > > > > > I'm still trying to find why I'm getting strange output of thread > > > information. While stopped > > > at NSH's cmd_pwd, I get this: > > > > > > ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 in > > > ?? ()\n" > > > > > > >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd > > > >(vtbl=0x20001fb0, argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" > > > > > > > > > If I just stopped randomly I get this: > > > > > > >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x74a0 in > > > >up_idle () at chip/nrf52_idle.c:191\n" > > > > > > >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x237c in > > > >g_idletcb ()\n" > > > > > > > > > So for some reason the PC of the active task is not read correctly. > > > > > > On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > > > > This is what I tried and works. This is much better than being forced > > > > > to use a specific configuration to get the offsets right or having to > > > > > rebuild openocd each time. > > > > > I will polish the approach and open a draft PR to show how it works. > > > > > > > > > > > > As I said above, you don't have to do that. The OpenOCD support > > > > relies on post file hooks to retrieve these information. > > > > https://github.com/sony/openocd-nuttx/wiki > > > > > > > > > > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt > > > > wrote: > > > > > > > > > > I wonder if we could automate that? Instead of separate debug vs > > > > > production configurations, could not configure.sh/c just create a > > > > > debug > > > > > configuration by disabling optimization, enabling symbols, enabling > > > > > debug features, assertions, basic error and warning output? > > > > > > > > > > Of course specialize configurations like a networking configure would > > > > > need more (like network debug), but changes like that to > > > > > configure.sh/c > > > > > would get you 90% there. > > > > > > > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > > > > Perfect! Let's do this as time permits. > > > > > > > > > > > > -Original Message- > > > > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > > > > Sent: Monday, November 23, 2020 5:09 AM > > > > > > To: dev@nuttx.apache.org > > > > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > > > > > > > On 11/23/20, Gregory Nutt wrote: > > > > > >> It has always been the policy to disable debug features in all > > > > > >> shipped > > > > > >> configurations. They were considered production configurations not > > > > > >> debug configurations. > > > > > >> > > > > > >> Configurations that have debug enable could, perhaps, be named like > > > > > >> nsh-debug. > > > > > >> > > > > > >> On 11/23/2020 5:38 AM, Alan Carvalho de Assis wrote: > > > > > >>> I think we need to have a good compromise between features and > > > > > >>> size. > > > > > >>> > > > > > >>> For instance, the default "nsh" demo should be small, basically > > > > > >>> just > > > > > >>> the terminal and minimum support to its commands to work, like the > > > > > >>> PROCFS to get 'free' working. > > > > > >>> > > > > > >>> Also keep in mind that for debugging purpose we need to "Suppress > > > > > >>> Optimization" that also will increase its size. > > > > > >>> > > > > > >>> So, I think it could be a good idea to have a predefined config
ESP32-C3 Leaked
https://hackaday.com/2020/11/22/espressif-leaks-esp32-c3-a-wifi-soc-thats-risc-v-and-is-esp8266-pin-compatible/ https://www.cnx-software.com/2020/11/22/esp32-c3-wifi-ble-risc-v-processor-is-pin-to-pin-compatible-with-esp8266/
Re: Should TASK_NAME_SIZE be changed in most configs?
My idea is to pick up g_statenames symbol, as nuttx-gdbinit does. However, I couldn't find a way to do this since it is a static array of character arrays, which requires knowledge of each entry length to be used. I guess there should be a way to do it but I couldn't figure it out. Best, Matias On Mon, Nov 23, 2020, at 16:02, Abdelatif Guettouche wrote: > The state names is an enumeration from the NuttX side. I'm not sure > if we can use the same technique to retrieve it. > > When adding the Xtensa/ESP32 stack info, I did some re-organisation > which should ease adding a new architecture. But that code will need > to wait for the next release before it will go to Espressif's fork in > Github (maybe a few days). > > On Mon, Nov 23, 2020 at 4:54 PM Matias N. wrote: > > > > Nevermind, I thought I needed to correct register offsets and I only messed > > them up. > > I added the commands to my gdb startup and now works as expected. Maybe we > > could do the same > > to pass register addresses for other architectures and to set the array of > > state names? > > > > On Mon, Nov 23, 2020, at 14:12, Abdelatif Guettouche wrote: > > > Can you see that NuttX was detected and the offsets are correct from > > > OpenOCD? > > > Do you have this in your OpenOCD config file: $_TARGETNAME configure > > > -rtos nuttx > > > > > > I do this with an STM32F4 > > > > > > source [find target/stm32f4x.cfg] > > > > > > $_TARGETNAME configure -rtos nuttx > > > > > > On Mon, Nov 23, 2020 at 4:00 PM Matias N. wrote: > > > > > > > > Ahh, I didn't know what you were refering to by "post file". I > > > > understand now. > > > > This should really be documented somewhere in our own docs, as I > > > > understand > > > > this should work with mainline openocd. > > > > > > > > Maybe this approach could be extended so that the number of tasks > > > > states is also > > > > obtained and does not have to be matched against openocd config. > > > > > > > > I'm still trying to find why I'm getting strange output of thread > > > > information. While stopped > > > > at NSH's cmd_pwd, I get this: > > > > > > > > ~" 2 Thread 536871672 (Name: Idle Task, pid:0, READYTORUN) 0x200014f4 > > > > in ?? ()\n" > > > > > > > > >~"* 5 Thread 536876144 (Name: init, pid:1, RUNNING) cmd_pwd > > > > >(vtbl=0x20001fb0, argc=1, argv=0x20001e3c) at nsh_envcmds.c:333\n" > > > > > > > > > > > > If I just stopped randomly I get this: > > > > > > > > >~"* 2 Thread 536871672 (Name: Idle Task, pid:0, RUNNING) 0x74a0 in > > > > >up_idle () at chip/nrf52_idle.c:191\n" > > > > > > > > >~" 5 Thread 536876144 (Name: init, pid:1, WAIT_SEM) 0x237c in > > > > >g_idletcb ()\n" > > > > > > > > > > > > So for some reason the PC of the active task is not read correctly. > > > > > > > > On Mon, Nov 23, 2020, at 13:47, Abdelatif Guettouche wrote: > > > > > > This is what I tried and works. This is much better than being > > > > > > forced > > > > > > to use a specific configuration to get the offsets right or having > > > > > > to rebuild openocd each time. > > > > > > I will polish the approach and open a draft PR to show how it works. > > > > > > > > > > > > > > > As I said above, you don't have to do that. The OpenOCD support > > > > > relies on post file hooks to retrieve these information. > > > > > https://github.com/sony/openocd-nuttx/wiki > > > > > > > > > > > > > > > On Mon, Nov 23, 2020 at 3:08 PM Gregory Nutt > > > > > wrote: > > > > > > > > > > > > I wonder if we could automate that? Instead of separate debug vs > > > > > > production configurations, could not configure.sh/c just create a > > > > > > debug > > > > > > configuration by disabling optimization, enabling symbols, enabling > > > > > > debug features, assertions, basic error and warning output? > > > > > > > > > > > > Of course specialize configurations like a networking configure > > > > > > would > > > > > > need more (like network debug), but changes like that to > > > > > > configure.sh/c > > > > > > would get you 90% there. > > > > > > > > > > > > On 11/23/2020 7:29 AM, David Sidrane wrote: > > > > > > > Perfect! Let's do this as time permits. > > > > > > > > > > > > > > -Original Message- > > > > > > > From: Alan Carvalho de Assis [mailto:acas...@gmail.com] > > > > > > > Sent: Monday, November 23, 2020 5:09 AM > > > > > > > To: dev@nuttx.apache.org > > > > > > > Subject: Re: Should TASK_NAME_SIZE be changed in most configs? > > > > > > > > > > > > > > Yes, I think nsh-debug will make its intention clear. > > > > > > > > > > > > > > On 11/23/20, Gregory Nutt wrote: > > > > > > >> It has always been the policy to disable debug features in all > > > > > > >> shipped > > > > > > >> configurations. They were considered production configurations > > > > > > >> not > > > > > > >> debug configurations. > > > > > > >> > > > > > > >> Configurations that have debug enable could, perhaps, be named > > > > > > >> like > > > > > > >> nsh-debug. > > > > > > >> > > > > > > >
Re[2]: iMXRT1064-EVK nshocram linking issue
Thank you for your prompt reply, David! I already have nsh config working from 4MB internal flash which starts from 0x7000. I am not using neither Hyperflash nor external flash. This has also been verified by measuring voltage values on CE low pins of each chip. Someone else was also successful in making it work from internal flash as described on github: https://github.com/apache/incubator-nuttx/issues/1494 The problem is making it work for nshocram configuration. I cannot seem to understand what that linking error means. Thank you. Vadim >Понедельник, 23 ноября 2020, 19:09 +03:00 от David Sidrane >: > >Hi Vadim, > >I do not recall all the deltas from the 1062 to the 1064. But the 1064 may >have other IP changes, and memory map differences > >You should create a board new directory imxrt1060-evk. And make the changes >there. > >You will need to know what kind of memory is embedded. Hyper flash or QSPI > >Also start with nsh config as nshocram is more complex. > >David > > >-Original Message- >From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID] >Sent: Monday, November 23, 2020 7:56 AM >To: dev@nuttx.apache.org >Subject: iMXRT1064-EVK nshocram linking issue > > >Hello, > >My name is Vadim. I am new to NuttX and to the embedded world in general. I >am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board >using 1060 configuration with changes to flash-ocram.ld and >imxrt_flexspi_nor_boot.h. > >In imxrt_flexspi_nor_boot.h, I changed FLASH_BASE from 0x6000 to >0x7000 . > >In flash-ocram.ld, I changed: >flash (rx) : ORIGIN and LENGTH from 0x6000 and 7M to 0x7000 >and 3M → changing origin address alone leads to this error. Everything links >with no issue otherwise (even with other changes excluding this one). >flashxip (rx) : ORIGIN and LENGTH from 0x6070 and 1M to 0x7030 >and 1M > > >I am getting relocation truncated to fit error: > >make[2]: Entering directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' >CC: imxrt_boot.c >CC: imxrt_flexspi_nor_boot.c >CC: imxrt_flexspi_nor_flash.c >CC: imxrt_appinit.c >CC: imxrt_bringup.c >CC: imxrt_autoleds.c >AR (create): libboard.a imxrt_boot.o imxrt_flexspi_nor_boot.o >imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o >make[2]: Leaving directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' >LD: nuttx >/usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0): >relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4' >make[1]: *** [Makefile:172: nuttx] Error 1 >make[1]: Leaving directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src' >make: *** [tools/Makefile.unix:423: nuttx] Error 2 > > > >I was wondering what needs to be done to make it work? > >Please, let me know. > >Thank you for your time. > >Regards, >Vadim
RE: Re[2]: iMXRT1064-EVK nshocram linking issue
Hi Vadim, Add an entry in section .flashxip or .text for the _udivmoddi4.o and move it to see if you can clear the error. See https://github.com/PX4/PX4-Autopilot/blob/master/boards/nxp/fmurt1062-v1/nuttx-config/scripts/ocram-script.ld#L105-L137 For what it takes to position an obj module. David -Original Message- From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID] Sent: Monday, November 23, 2020 11:33 AM To: dev@nuttx.apache.org Subject: Re[2]: iMXRT1064-EVK nshocram linking issue Thank you for your prompt reply, David! I already have nsh config working from 4MB internal flash which starts from 0x7000. I am not using neither Hyperflash nor external flash. This has also been verified by measuring voltage values on CE low pins of each chip. Someone else was also successful in making it work from internal flash as described on github: https://github.com/apache/incubator-nuttx/issues/1494 The problem is making it work for nshocram configuration. I cannot seem to understand what that linking error means. Thank you. Vadim >Понедельник, 23 ноября 2020, 19:09 +03:00 от David Sidrane >: > >Hi Vadim, > >I do not recall all the deltas from the 1062 to the 1064. But the 1064 may >have other IP changes, and memory map differences > >You should create a board new directory imxrt1060-evk. And make the changes >there. > >You will need to know what kind of memory is embedded. Hyper flash or QSPI > >Also start with nsh config as nshocram is more complex. > >David > > >-Original Message- >From: Вадим Ястребов [mailto:woody_haw...@mail.ru.INVALID] >Sent: Monday, November 23, 2020 7:56 AM >To: dev@nuttx.apache.org >Subject: iMXRT1064-EVK nshocram linking issue > > >Hello, > >My name is Vadim. I am new to NuttX and to the embedded world in general. I >am trying to compile NuttX nshocram configuration for IMXRT1064-EVK board >using 1060 configuration with changes to flash-ocram.ld and >imxrt_flexspi_nor_boot.h. > >In imxrt_flexspi_nor_boot.h, I changed FLASH_BASE from 0x6000 to >0x7000 . > >In flash-ocram.ld, I changed: >flash (rx) : ORIGIN and LENGTH from 0x6000 and 7M to 0x7000 >and 3M → changing origin address alone leads to this error. Everything >links >with no issue otherwise (even with other changes excluding this one). >flashxip (rx) : ORIGIN and LENGTH from 0x6070 and 1M to 0x7030 >and 1M > > >I am getting relocation truncated to fit error: > >make[2]: Entering directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' >CC: imxrt_boot.c >CC: imxrt_flexspi_nor_boot.c >CC: imxrt_flexspi_nor_flash.c >CC: imxrt_appinit.c >CC: imxrt_bringup.c >CC: imxrt_autoleds.c >AR (create): libboard.a imxrt_boot.o imxrt_flexspi_nor_boot.o >imxrt_flexspi_nor_flash.o imxrt_appinit.o imxrt_bringup.o imxrt_autoleds.o >make[2]: Leaving directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/boards/arm/imxrt/imxrt1060-evk/src' >LD: nuttx >/usr/lib/gcc/arm-none-eabi/10.2.0/thumb/v7e-m+dp/hard/libgcc.a(_udivmoddi4.o):(.ARM.exidx.text.__udivmoddi4+0x0): >relocation truncated to fit : R_ARM_PREL31 against `.text.__udivmoddi4' >make[1]: *** [Makefile:172: nuttx] Error 1 >make[1]: Leaving directory >'/home/vadim/Downloads/nuttx_nov20/nuttx/arch/arm/src' >make: *** [tools/Makefile.unix:423: nuttx] Error 2 > > > >I was wondering what needs to be done to make it work? > >Please, let me know. > >Thank you for your time. > >Regards, >Vadim
Getting stuck in _up_assert()
Some months ago I implemented the basic architectural support for STM32G47xxx and I noticed that occasionally, during startup, I am getting stuck in _up_assert(). It is not happening consistently. It's intermittent. I'm not really sure why. Any ideas what I should look for? Here is the backtrace: Program received signal SIGINT, Interrupt. _up_assert () at armv7-m/arm_assert.c:353 (gdb) backtrace #0 _up_assert () at armv7-m/arm_assert.c:353 #1 0x0800e2e4 in up_assert (filename=0x8013bc8 "armv7-m/arm_hardfault.c", lineno=134) at armv7-m/arm_assert.c:428 #2 0x080092e2 in _assert (filename=0x8013bc8 "armv7-m/arm_hardfault.c", linenum=134) at assert/lib_assert.c:36 #3 0x08000fb8 in arm_hardfault (irq=3, context=0x20001754, arg=0x0) at armv7-m/arm_hardfault.c:134 #4 0x08004d7c in irq_dispatch (irq=3, context=0x20001754) at irq/irq_dispatch.c:183 #5 0x08000b80 in arm_doirq (irq=3, regs=0x20001754) at armv7-m/arm_doirq.c:71 #6 0x08000b02 in exception_common () at armv7-m/gnu/arm_lazyexception.S:208 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thanks, Nathan
Re: Getting stuck in _up_assert()
You can try the section on hardfault debugging here: https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That starts at slide 17: /Set a breakpoint on up_hardfault and up_assert//Set the PC equal to the LR//Select assembly single step//And step to bx lr instruction in do_irq that will return you to the line of code //that caused the HardFault/ On 11/23/2020 3:07 PM, Nathan Hartman wrote: Some months ago I implemented the basic architectural support for STM32G47xxx and I noticed that occasionally, during startup, I am getting stuck in _up_assert(). It is not happening consistently. It's intermittent. I'm not really sure why. Any ideas what I should look for? Here is the backtrace: Program received signal SIGINT, Interrupt. _up_assert () at armv7-m/arm_assert.c:353 (gdb) backtrace #0 _up_assert () at armv7-m/arm_assert.c:353 #1 0x0800e2e4 in up_assert (filename=0x8013bc8 "armv7-m/arm_hardfault.c", lineno=134) at armv7-m/arm_assert.c:428 #2 0x080092e2 in _assert (filename=0x8013bc8 "armv7-m/arm_hardfault.c", linenum=134) at assert/lib_assert.c:36 #3 0x08000fb8 in arm_hardfault (irq=3, context=0x20001754, arg=0x0) at armv7-m/arm_hardfault.c:134 #4 0x08004d7c in irq_dispatch (irq=3, context=0x20001754) at irq/irq_dispatch.c:183 #5 0x08000b80 in arm_doirq (irq=3, regs=0x20001754) at armv7-m/arm_doirq.c:71 #6 0x08000b02 in exception_common () at armv7-m/gnu/arm_lazyexception.S:208 Backtrace stopped: previous frame inner to this frame (corrupt stack?) Thanks, Nathan
Re: Getting stuck in _up_assert()
I'm thiking that we could extend nuttx-gdbinit so that it offers an easy way to see registeres from CURRENT_REGS so that you can get a register dump without a console. Also, we could have a function that could take the LR and set the PC in order to go to most likely place of hardfault automatically with a single command. I'm also curious if the current support for tracking nuttx threads wouldn't already provide enough context to figure that out since you will know where every task was before the fault. On Mon, Nov 23, 2020, at 19:17, Gregory Nutt wrote: > You can try the section on hardfault debugging here: > https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That > starts at slide 17: > > /Set a breakpoint on up_hardfault and up_assert//Set the PC equal to > the LR//Select assembly single step//And step to bx lr instruction > in do_irq that will return you to the line of code //that caused the > HardFault/ > > On 11/23/2020 3:07 PM, Nathan Hartman wrote: > > Some months ago I implemented the basic architectural support for > > STM32G47xxx and I noticed that occasionally, during startup, I am > > getting stuck in _up_assert(). It is not happening consistently. It's > > intermittent. I'm not really sure why. Any ideas what I should look > > for? Here is the backtrace: > > > > Program received signal SIGINT, Interrupt. > > _up_assert () at armv7-m/arm_assert.c:353 > > (gdb) backtrace > > #0 _up_assert () at armv7-m/arm_assert.c:353 > > #1 0x0800e2e4 in up_assert (filename=0x8013bc8 > > "armv7-m/arm_hardfault.c", lineno=134) at armv7-m/arm_assert.c:428 > > #2 0x080092e2 in _assert (filename=0x8013bc8 > > "armv7-m/arm_hardfault.c", linenum=134) at assert/lib_assert.c:36 > > #3 0x08000fb8 in arm_hardfault (irq=3, context=0x20001754, arg=0x0) > > at armv7-m/arm_hardfault.c:134 > > #4 0x08004d7c in irq_dispatch (irq=3, context=0x20001754) at > > irq/irq_dispatch.c:183 > > #5 0x08000b80 in arm_doirq (irq=3, regs=0x20001754) at > > armv7-m/arm_doirq.c:71 > > #6 0x08000b02 in exception_common () at armv7-m/gnu/arm_lazyexception.S:208 > > Backtrace stopped: previous frame inner to this frame (corrupt stack?) > > > > Thanks, > > Nathan >
Re: Getting stuck in _up_assert()
On Mon, Nov 23, 2020 at 5:18 PM Gregory Nutt wrote: > You can try the section on hardfault debugging here: > https://nuttx.events/wp-content/uploads/2019/11/DSidrane_nx2019.pdf That > starts at slide 17: > > /Set a breakpoint on up_hardfault and up_assert//Set the PC equal to > the LR//Select assembly single step//And step to bx lr instruction > in do_irq that will return you to the line of code //that caused the > HardFault/ > Thanks. I have to wait for it to happen again. It's very intermittent. I'll keep the list posted when I discover the cause. Thanks again, Nathan
