[VOTE] Apache NuttX 12.1.0 RC0 release

2023-04-11 Thread Alin Jerpelea 
Hello all,
Apache NuttX 12.1.0 RC0 has been staged under [1] and it's
time to vote on accepting it for release. Voting will be open for 72hr.

A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
required to pass.

The Apache requirements for approving a release can be found here [3]
"Before voting +1 [P]PMC members are required to download the signed
source code package, compile it as provided, and test the resulting
executable on their own platform, along with also verifying that the
package meets the requirements of the ASF policy on releases."

A document to walk through some of this process has been published on
our project wiki and can be found here [4].

[ ] +1 accept (indicate what you validated - e.g. performed the non-RM
items in [4])
[ ] -1 reject (explanation required)

Thank you all,
Alin Jerpelea

SCM Information:
  Release tag: nuttx-12.1.0-RC0
  Hash for the release nuttx tag: d40f4032fc5491d2aeb9fde37042a5be9eabeb15
  Hash for the release nuttx-apps tag: 125cf7abe2d7f345c3bc58c0bdea2360fdefa170

[1] https://dist.apache.org/repos/dist/dev/nuttx/12.1.0-RC0/
[2] https://raw.githubusercontent.com/apache/nuttx/nuttx-12.1.0-RC0/ReleaseNotes
[3] https://www.apache.org/dev/release.html#approving-a-release
[4] 
https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

2023-04-11 Thread David Sidrane 
@slorquet Please have a look at #8992. Let me know if it addresses all the
concerns you have.

-Original Message-
From: Sebastien Lorquet 
Sent: Friday, April 7, 2023 9:58 AM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

Thanks for the notification.

Your proposal is mostly OK for me, I hope others will send reactions too. I
have just one concern.


If I attempt to rephrase the proposal: Starting from a commit in a
future, stm32h7 GPIO definitions will not include speed indications
anymore, and these will have to be added manually in board.h, but ONLY
if the LEGACY_PINMAP is not set?


Here is my concern: What will happen if a user (me, probably) builds a
NuttX with this new commit from a full stored defconfig, but does not
regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
will not be present when building in that case.

Can we force a config update before starting the build, so the
LEGACY_PINMAP setting will be set to Y automatically in all cases?


Also, this has to be documented very clearly, not just the official
release notes for the next release!

Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
compile time warning in stm32h7/stm32_gpio.c that in the future, users
are required to update their board.h and once done, disable LEGACY_PINMAP ?

Sebastien


Le 07/04/2023 à 15:34, David Sidrane a écrit :
> Opening the discussion for this issue on the list. See
> https://github.com/apache/nuttx/issues/1570
>
>
>
> I would like to get feedback on the approach see if we can move forward on
> this.
>
>
>
>
>
> While some solutions were discussed in
>
> - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> mode."
>  #5012 
>
> I would like to propose a solution for this issue as a request for
> comment:
>
> 1. That will not affect any existing boards
> 2. Will allow us to fix the issues without forcing massive changes.
> 3. Eventually after N more releases of NuttX deprecate the solution.
>
> Steps to get there:
>
> 1. Kconfig for all effected arches will have
> STM32xxx_USE_LEGACY_PINMAP
> set to yes as a default.
> 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> 3. The current pinmap file will be renamed with _legacy E.G.
> hardware/stm32h7x3xx_pinmap_legacy.h
> 4. Rework chip specific files removing speeds and adding _0 to the
> previous no-selectable pins with speeds
> 5. Rework chip specific files adding _0 to the previous no-selectable
> pins
>
> The hardware/stm32_pinmap.h will have the following structure
>
> #if defined(STM32H7_USE_LEGACY_PINMAP )
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap_legacy.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Legacy Pin map"
>
> #  endif
>
> #else
>
> #  if defined(CONFIG_STM32H7_STM32H7X3XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
>
> #include "hardware/stm32h7x3xx_pinmap.h"
>
> #  else
>
> # error "Unsupported STM32 H7 Pin map"
>
> #  endif
>
> # endif
>
>
>
> Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
> the board.h files to fully define
> the pins with selected speeds.
>
> was:
>
> #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
>
> #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */
>
> //  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */
>
> //  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */
>
> #define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */
>
> //  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */
>
> is:
>
> #define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
> PD6  FC_PD6_SDMMC2_CK  */
>
> #define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CMD_1 |  GPIO_SPEED_2MHz)  /*
> PD7  FC_PD7_SDMMC2_CMD */
>
> #define GPIO_SDMMC2_D0   (GPIO_SDMMC2_D0_0  | GPIO_SPEED_2MHz) /* PB14
> FC_PB14_SDMMC2_D0 */
>
> #define GPIO_SDMMC2_D1   (GPIO_SDMMC2_D1_0  |  GPIO_SPEED_2MHz)/* PB15
> FC_PB15_SDMMC2_D1 */
>
> #define GPIO_SDMMC2_D2GPIO_SDMMC2_D2_1  | GPIO_SPEED_2MHz)  /*
> PG11 FC_PG11_SDMMC2_D2 */
>
> #define GPIO_SDMMC2_D3   (GPIO_SDMMC2_D3_0  | GPIO_SPEED_2MHz) /* PB4
> FC_PB4_SDMMC2_D3  */
>
>
>
> To maintain the speed that was set in the legacy files just diff the
> _legacy file
> with the non legacy file and use that
> speed when creating the #define.
>

Re: [VOTE] Apache NuttX 12.1.0 RC0 release

2023-04-11 Thread Lee, Lup Yuen 
+1 for PinePhone

= Compiler
+ aarch64-none-elf-gcc -v
Using built-in specs.
COLLECT_GCC=aarch64-none-elf-gcc
COLLECT_LTO_WRAPPER=/Applications/ArmGNUToolchain/11.3.rel1/aarch64-none-elf/bin/../libexec/gcc/aarch64-none-elf/11.3.1/lto-wrapper
Target: aarch64-none-elf
Configured with:
/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/src/gcc/configure
--target=aarch64-none-elf
--prefix=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install
--with-gmp=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools
--with-mpfr=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools
--with-mpc=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools
--with-isl=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/host-tools
--disable-shared --disable-nls --disable-threads --disable-tls
--enable-checking=release --enable-languages=c,c++,fortran --with-newlib
--with-gnu-as --with-gnu-ld
--with-sysroot=/Volumes/data/jenkins/workspace/GNU-toolchain/arm-11/build-aarch64-none-elf/install/aarch64-none-elf
--with-pkgversion='Arm GNU Toolchain 11.3.Rel1' --with-bugurl=
https://bugs.linaro.org/
Thread model: single
Supported LTO compression algorithms: zlib
gcc version 11.3.1 20220712 (Arm GNU Toolchain 11.3.Rel1)

= Configuration
+ ./tools/configure.sh pinephone:nsh

= Size
+ aarch64-none-elf-size nuttx
   text   databssdechex filename
 218576  12897  41575 273048  42a98 nuttx

= NSH Info and Free
NuttShell (NSH) NuttX-12.1.0
nsh> name -a
NuttX 12.1.0 d40f4032fc Apr 12 2023 07:11:20 arm64 pinephone
nsh> free
   total   used   freelargest  nused  nfree
Umem:  133414240 550768  132863472  132863376 56  2

Complete Log:
https://gist.github.com/lupyuen/5760e0375d44a06b3c730a10614e4d24

Validation Script:
https://gist.github.com/lupyuen/a08d3d478beefc5a492ed2dae39438f3

Lup

On Tue, Apr 11, 2023 at 4:52 PM Alin Jerpelea  wrote:

> Hello all,
> Apache NuttX 12.1.0 RC0 has been staged under [1] and it's
> time to vote on accepting it for release. Voting will be open for 72hr.
>
> A minimum of 3 binding +1 votes and more binding +1 than binding -1 are
> required to pass.
>
> The Apache requirements for approving a release can be found here [3]
> "Before voting +1 [P]PMC members are required to download the signed
> source code package, compile it as provided, and test the resulting
> executable on their own platform, along with also verifying that the
> package meets the requirements of the ASF policy on releases."
>
> A document to walk through some of this process has been published on
> our project wiki and can be found here [4].
>
> [ ] +1 accept (indicate what you validated - e.g. performed the non-RM
> items in [4])
> [ ] -1 reject (explanation required)
>
> Thank you all,
> Alin Jerpelea
>
> SCM Information:
>   Release tag: nuttx-12.1.0-RC0
>   Hash for the release nuttx tag: d40f4032fc5491d2aeb9fde37042a5be9eabeb15
>   Hash for the release nuttx-apps tag:
> 125cf7abe2d7f345c3bc58c0bdea2360fdefa170
>
> [1] https://dist.apache.org/repos/dist/dev/nuttx/12.1.0-RC0/
> [2]
> https://raw.githubusercontent.com/apache/nuttx/nuttx-12.1.0-RC0/ReleaseNotes
> [3] https://www.apache.org/dev/release.html#approving-a-release
> [4]
> https://cwiki.apache.org/confluence/display/NUTTX/Validating+a+staged+Release
>

Re: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

2023-04-11 Thread Nathan Hartman 
@davids5, I saw the request on GitHub for help with the STM32G families but
unfortunately something has come up and I won't be able to work on it this
week. Hopefully someone else can volunteer, otherwise I'll try to help next
week...

Thanks,
Nathan

On Tue, Apr 11, 2023 at 7:58 AM David Sidrane 
wrote:

> @slorquet Please have a look at #8992. Let me know if it addresses all the
> concerns you have.
>
> -Original Message-
> From: Sebastien Lorquet 
> Sent: Friday, April 7, 2023 9:58 AM
> To: dev@nuttx.apache.org
> Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
> Slew-rate and Frequency) Settings #1570
>
> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions too. I
> have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add a
> compile time warning in stm32h7/stm32_gpio.c that in the future, users
> are required to update their board.h and once done, disable LEGACY_PINMAP ?
>
> Sebastien
>
>
> Le 07/04/2023 à 15:34, David Sidrane a écrit :
> > Opening the discussion for this issue on the list. See
> > https://github.com/apache/nuttx/issues/1570
> >
> >
> >
> > I would like to get feedback on the approach see if we can move forward
> on
> > this.
> >
> >
> >
> >
> >
> > While some solutions were discussed in
> >
> > - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> > mode."
> >  #5012 
> >
> > I would like to propose a solution for this issue as a request for
> > comment:
> >
> > 1. That will not affect any existing boards
> > 2. Will allow us to fix the issues without forcing massive changes.
> > 3. Eventually after N more releases of NuttX deprecate the solution.
> >
> > Steps to get there:
> >
> > 1. Kconfig for all effected arches will have
> > STM32xxx_USE_LEGACY_PINMAP
> > set to yes as a default.
> > 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> > 3. The current pinmap file will be renamed with _legacy E.G.
> > hardware/stm32h7x3xx_pinmap_legacy.h
> > 4. Rework chip specific files removing speeds and adding _0 to the
> > previous no-selectable pins with speeds
> > 5. Rework chip specific files adding _0 to the previous no-selectable
> > pins
> >
> > The hardware/stm32_pinmap.h will have the following structure
> >
> > #if defined(STM32H7_USE_LEGACY_PINMAP )
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Legacy Pin map"
> >
> > #  endif
> >
> > #else
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Pin map"
> >
> > #  endif
> >
> > # endif
> >
> >
> >
> > Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and update
> > the board.h files to fully define
> > the pins with selected speeds.
> >
> > was:
> >
> > #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD */
> >
> > //  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */
> >
> > //  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */
> >
> > #define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */
> >
> > //  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */
> >
> > is:
> >
> > #define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
> > PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CMD_1 |  GPIO_SPEED_2MHz)  /*
> > PD7  FC_PD7_SDMMC2_CMD */
> >
> > #define GPIO_SDMMC2_D0   (GPIO_SDMMC2_D0_0  | GPIO_SPEED_2MHz) /* PB14
> > FC_PB14_SDMMC2_D0 */
> >
> > #define GPIO_SDMMC2_D1   (GPIO_SDMMC2_D1_0  |  GPIO_SPEED_2MHz)/* PB15
> > FC_PB15_SDMMC2_D1 */
> >
> > #define GPIO_SDMMC2_D2GPIO_SDMMC2_D2

Re: [VOTE] Apache NuttX 12.1.0 RC0 release

2023-04-11 Thread Tomek CEDRO 
Quick test on FreeBSD AMD64 13.2-RELEASE-p0 (upgraded today from
13.1-RELEASE-p6).

FreeBSD octagon 13.2-RELEASE FreeBSD 13.2-RELEASE
releng/13.2-n254617-525ecfdad597 GENERIC amd64

ESP32 builds work fine, but sim:nsh build fails at linking backtrace o_O



1. ESP32-DEVKITC (OK, log truncated)

1.1. CoreMark (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:coremark
gmake
gmake flash ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0
Running CoreMark...
2K performance run parameters for coremark.
CoreMark Size: 666
Total ticks  : 12180
Total time (secs): 12.18
Iterations/Sec   : 985.221675
Iterations   : 12000
Compiler version : GCC8.4.0
Compiler flags   : -O3 -fno-strict-aliasing -fomit-frame-pointer
-ffunction-sections -fdata-sections
Parallel PThreads : 2
Memory location  : Stack
seedcrc  : 0xe9f5
[0]crclist   : 0xe714
[1]crclist   : 0xe714
[0]crcmatrix : 0x1fd7
[1]crcmatrix : 0x1fd7
[0]crcstate  : 0x8e3a
[1]crcstate  : 0x8e3a
[0]crcfinal  : 0xa14c
[1]crcfinal  : 0xa14c
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 985.221675 / GCC8.4.0 -O3 -fno-strict-aliasing
-fomit-frame-pointer -ffunction-sections -fdata-sections / Stack /
2:PThreads


1.2. NSH (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:nsh
gmake
gmake flash ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0

NuttShell (NSH) NuttX-12.1.0
nsh> uname -a
NuttX 12.1.0 d40f4032fc-dirty Apr 12 2023 04:26:43 xtensa esp32-devkitc
nsh> exit
~
[EOT]


2. SIM (build error in nsh)

2.1. ostest (OK)

gmake distclean
./tools/configure.sh -B sim:ostest
gmake

./nuttx
stdio_test: write fd=1
stdio_test: Standard I/O Check: printf
stdio_test: write fd=2
stdio_test: Standard I/O Check: fprintf to stderr
ostest_main: putenv(Variable1=BadValue3)
ostest_main: setenv(Variable1, GoodValue1, TRUE)
ostest_main: setenv(Variable2, BadValue1, FALSE)
ostest_main: setenv(Variable2, GoodValue2, TRUE)
ostest_main: setenv(Variable3, GoodValue3, FALSE)
ostest_main: setenv(Variable3, BadValue2, FALSE)
show_variable: Variable=Variable1 has value=GoodValue1
show_variable: Variable=Variable2 has value=GoodValue2
show_variable: Variable=Variable3 has value=GoodValue3
ostest_main: Started user_main at PID=4

user_main: Begin argument test
user_main: Started with argc=5
user_main: argv[0]="ostest"
user_main: argv[1]="Arg1"
user_main: argv[2]="Arg2"
user_main: argv[3]="Arg3"
user_main: argv[4]="Arg4"

End of test memory usage:
VARIABLE  BEFORE   AFTER
  
arena 3fffd80  3fffd80
ordblks 22
mxordblk  3fb9a40  3fb9a40
uordblks4631046310
fordblks  3fb9a70  3fb9a70

user_main: getopt() test
getopt():  Simple test
getopt():  Invalid argument
getopt():  Missing optional argument
getopt_long():  Simple test
getopt_long():  No short options
getopt_long():  Argument for --option=argument
getopt_long():  Invalid long option
getopt_long():  Mixed long and short options
getopt_long():  Invalid short option
getopt_long():  Missing optional arguments
getopt_long_only():  Mixed long and short options
getopt_long_only():  Single hyphen long options


2.2. nsh (ERROR undefined symbol: backtrace)

 gmake clean distclean
./tools/configure.sh -B sim:nsh
  Copy files
  Select CONFIG_HOST_BSD=y
  Refreshing...
CP: arch/dummy/Kconfig to
/zraid/data/XXX/nuttxworkspace.git/nuttx/arch/dummy/dummy_kconfig
CP: boards/dummy/Kconfig to
/XXX/nuttxworkspace.git/nuttx/boards/dummy/dummy_kconfig
LN: platform/board to /XXX/nuttxworkspace.git/apps/platform/dummy
LN: include/arch to arch/sim/include
LN: include/arch/board to
/XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/include
LN: drivers/platform to /XXX/nuttxworkspace.git/nuttx/drivers/dummy
LN: include/arch/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/include/sim
LN: arch/sim/src/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/src/sim
LN: arch/sim/src/board to /XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/src
mkkconfig in /XXX/nuttxworkspace.git/apps/audioutils
mkkconfig in /XXX/nuttxworkspace.git/apps/benchmarks
mkkconfig in /XXX/nuttxworkspace.git/apps/boot
mkkconfig in /XXX/nuttxworkspace.git/apps/canutils
mkkconfig in /XXX/nuttxworkspace.git/apps/crypto
mkkconfig in /XXX/nuttxworkspace.git/apps/examples/mcuboot
mkkconfig in /XXX/nuttxworkspace.git/apps/examples
mkkconfig in /XXX/nuttxworkspace.git/apps/fsutils
mkkconfig in

RE: [VOTE] Apache NuttX 12.1.0 RC0 release

2023-04-11 Thread alin.jerpe...@sony.com 
@Tomek 

We need +1 or -1

Does the "ERROR undefined symbol: backtrace " error appear on master?

Thanks 
Alin


-Original Message-
From: Tomek CEDRO  
Sent: den 12 april 2023 05:45
To: dev@nuttx.apache.org
Subject: Re: [VOTE] Apache NuttX 12.1.0 RC0 release

Quick test on FreeBSD AMD64 13.2-RELEASE-p0 (upgraded today from 
13.1-RELEASE-p6).

FreeBSD octagon 13.2-RELEASE FreeBSD 13.2-RELEASE
releng/13.2-n254617-525ecfdad597 GENERIC amd64

ESP32 builds work fine, but sim:nsh build fails at linking backtrace o_O



1. ESP32-DEVKITC (OK, log truncated)

1.1. CoreMark (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:coremark gmake gmake flash 
ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0
Running CoreMark...
2K performance run parameters for coremark.
CoreMark Size: 666
Total ticks  : 12180
Total time (secs): 12.18
Iterations/Sec   : 985.221675
Iterations   : 12000
Compiler version : GCC8.4.0
Compiler flags   : -O3 -fno-strict-aliasing -fomit-frame-pointer
-ffunction-sections -fdata-sections
Parallel PThreads : 2
Memory location  : Stack
seedcrc  : 0xe9f5
[0]crclist   : 0xe714
[1]crclist   : 0xe714
[0]crcmatrix : 0x1fd7
[1]crcmatrix : 0x1fd7
[0]crcstate  : 0x8e3a
[1]crcstate  : 0x8e3a
[0]crcfinal  : 0xa14c
[1]crcfinal  : 0xa14c
Correct operation validated. See README.md for run and reporting rules.
CoreMark 1.0 : 985.221675 / GCC8.4.0 -O3 -fno-strict-aliasing 
-fomit-frame-pointer -ffunction-sections -fdata-sections / Stack / 2:PThreads


1.2. NSH (OK)

gmake distclean
./tools/configure.sh -B esp32-devkitc:nsh gmake gmake flash 
ESPTOOL_PORT=/dev/cuaU0 ESPTOOL_BAUD=115200

cu -l /dev/cuaU0 -s 115200

rst:0x1 (POWERON_RESET),boot:0x13 (SPI_FAST_FLASH_BOOT)
configsip: 0, SPIWP:0xee
clk_drv:0x00,q_drv:0x00,d_drv:0x00,cs0_drv:0x00,hd_drv:0x00,wp_drv:0x00
mode:DIO, clock div:2
load:0x3fff0030,len:5656
load:0x40078000,len:12696
load:0x40080400,len:4292
entry 0x400806b0

NuttShell (NSH) NuttX-12.1.0
nsh> uname -a
NuttX 12.1.0 d40f4032fc-dirty Apr 12 2023 04:26:43 xtensa esp32-devkitc
nsh> exit
~
[EOT]


2. SIM (build error in nsh)

2.1. ostest (OK)

gmake distclean
./tools/configure.sh -B sim:ostest
gmake

./nuttx
stdio_test: write fd=1
stdio_test: Standard I/O Check: printf
stdio_test: write fd=2
stdio_test: Standard I/O Check: fprintf to stderr
ostest_main: putenv(Variable1=BadValue3)
ostest_main: setenv(Variable1, GoodValue1, TRUE)
ostest_main: setenv(Variable2, BadValue1, FALSE)
ostest_main: setenv(Variable2, GoodValue2, TRUE)
ostest_main: setenv(Variable3, GoodValue3, FALSE)
ostest_main: setenv(Variable3, BadValue2, FALSE)
show_variable: Variable=Variable1 has value=GoodValue1
show_variable: Variable=Variable2 has value=GoodValue2
show_variable: Variable=Variable3 has value=GoodValue3
ostest_main: Started user_main at PID=4

user_main: Begin argument test
user_main: Started with argc=5
user_main: argv[0]="ostest"
user_main: argv[1]="Arg1"
user_main: argv[2]="Arg2"
user_main: argv[3]="Arg3"
user_main: argv[4]="Arg4"

End of test memory usage:
VARIABLE  BEFORE   AFTER
  
arena 3fffd80  3fffd80
ordblks 22
mxordblk  3fb9a40  3fb9a40
uordblks4631046310
fordblks  3fb9a70  3fb9a70

user_main: getopt() test
getopt():  Simple test
getopt():  Invalid argument
getopt():  Missing optional argument
getopt_long():  Simple test
getopt_long():  No short options
getopt_long():  Argument for --option=argument
getopt_long():  Invalid long option
getopt_long():  Mixed long and short options
getopt_long():  Invalid short option
getopt_long():  Missing optional arguments
getopt_long_only():  Mixed long and short options
getopt_long_only():  Single hyphen long options


2.2. nsh (ERROR undefined symbol: backtrace)

 gmake clean distclean
./tools/configure.sh -B sim:nsh
  Copy files
  Select CONFIG_HOST_BSD=y
  Refreshing...
CP: arch/dummy/Kconfig to
/zraid/data/XXX/nuttxworkspace.git/nuttx/arch/dummy/dummy_kconfig
CP: boards/dummy/Kconfig to
/XXX/nuttxworkspace.git/nuttx/boards/dummy/dummy_kconfig
LN: platform/board to /XXX/nuttxworkspace.git/apps/platform/dummy
LN: include/arch to arch/sim/include
LN: include/arch/board to
/XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/include
LN: drivers/platform to /XXX/nuttxworkspace.git/nuttx/drivers/dummy
LN: include/arch/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/include/sim
LN: arch/sim/src/chip to /XXX/nuttxworkspace.git/nuttx/arch/sim/src/sim
LN: arch/sim/src/board to /XXX/nuttxworkspace.git/nuttx/boards/sim/sim/sim/src
mkkconfig in /XXX/nuttxworkspace.git/apps/audioutils
mkkconfig in /XXX/nuttxworkspace.git/apps/benchmarks
mkkconfig in /XXX/nuttxworkspace.git/apps/boot m

RE: Hardcoded Pin mux, pad control and Drive Strength (AKA Slew-rate and Frequency) Settings #1570

2023-04-11 Thread David Sidrane 
Nathan, no worries. I ended up doing the STM32G families yesterday.

David



-Original Message-
From: Nathan Hartman 
Sent: Tuesday, April 11, 2023 10:40 PM
To: dev@nuttx.apache.org
Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
Slew-rate and Frequency) Settings #1570

@davids5, I saw the request on GitHub for help with the STM32G families but
unfortunately something has come up and I won't be able to work on it this
week. Hopefully someone else can volunteer, otherwise I'll try to help next
week...

Thanks,
Nathan

On Tue, Apr 11, 2023 at 7:58 AM David Sidrane 
wrote:

> @slorquet Please have a look at #8992. Let me know if it addresses all
> the concerns you have.
>
> -Original Message-
> From: Sebastien Lorquet 
> Sent: Friday, April 7, 2023 9:58 AM
> To: dev@nuttx.apache.org
> Subject: Re: Hardcoded Pin mux, pad control and Drive Strength (AKA
> Slew-rate and Frequency) Settings #1570
>
> Thanks for the notification.
>
> Your proposal is mostly OK for me, I hope others will send reactions
> too. I have just one concern.
>
>
> If I attempt to rephrase the proposal: Starting from a commit in a
> future, stm32h7 GPIO definitions will not include speed indications
> anymore, and these will have to be added manually in board.h, but ONLY
> if the LEGACY_PINMAP is not set?
>
>
> Here is my concern: What will happen if a user (me, probably) builds a
> NuttX with this new commit from a full stored defconfig, but does not
> regenerate its config prior to rebuilding ? the LEGACY_PINMAP setting
> will not be present when building in that case.
>
> Can we force a config update before starting the build, so the
> LEGACY_PINMAP setting will be set to Y automatically in all cases?
>
>
> Also, this has to be documented very clearly, not just the official
> release notes for the next release!
>
> Aditionnally, if LEGACY_PINMAP is set in user config, maybe we can add
> a compile time warning in stm32h7/stm32_gpio.c that in the future,
> users are required to update their board.h and once done, disable
> LEGACY_PINMAP ?
>
> Sebastien
>
>
> Le 07/04/2023 à 15:34, David Sidrane a écrit :
> > Opening the discussion for this issue on the list. See
> > https://github.com/apache/nuttx/issues/1570
> >
> >
> >
> > I would like to get feedback on the approach see if we can move
> > forward
> on
> > this.
> >
> >
> >
> >
> >
> > While some solutions were discussed in
> >
> > - Revert "stm32h7 sdmmc: set SDMMC_CK pin to high speed (50 MHz)
> > mode."
> >  #5012 
> >
> > I would like to propose a solution for this issue as a request for
> > comment:
> >
> > 1. That will not affect any existing boards
> > 2. Will allow us to fix the issues without forcing massive changes.
> > 3. Eventually after N more releases of NuttX deprecate the solution.
> >
> > Steps to get there:
> >
> > 1. Kconfig for all effected arches will have
> > STM32xxx_USE_LEGACY_PINMAP
> > set to yes as a default.
> > 2. Rework top level pinmap files E.G. hardware/stm32_pinmap.h.
> > 3. The current pinmap file will be renamed with _legacy E.G.
> > hardware/stm32h7x3xx_pinmap_legacy.h
> > 4. Rework chip specific files removing speeds and adding _0 to the
> > previous no-selectable pins with speeds
> > 5. Rework chip specific files adding _0 to the previous
> > no-selectable
> > pins
> >
> > The hardware/stm32_pinmap.h will have the following structure
> >
> > #if defined(STM32H7_USE_LEGACY_PINMAP )
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap_legacy.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Legacy Pin map"
> >
> > #  endif
> >
> > #else
> >
> > #  if defined(CONFIG_STM32H7_STM32H7X3XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  elif defined(CONFIG_STM32H7_STM32H7X7XX)
> >
> > #include "hardware/stm32h7x3xx_pinmap.h"
> >
> > #  else
> >
> > # error "Unsupported STM32 H7 Pin map"
> >
> > #  endif
> >
> > # endif
> >
> >
> >
> > Moving forward boards will turn off STM32xx_USE_LEGACY_PINMAP and
> > update the board.h files to fully define the pins with selected
> > speeds.
> >
> > was:
> >
> > #define GPIO_SDMMC2_CK   GPIO_SDMMC2_CK_1  /* PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  GPIO_SDMMC2_CMD_1 /* PD7  FC_PD7_SDMMC2_CMD
> > */
> >
> > //  GPIO_SDMMC2_D0   No Remap  /* PB14 FC_PB14_SDMMC2_D0 */
> >
> > //  GPIO_SDMMC2_D1   No Remap  /* PB15 FC_PB15_SDMMC2_D1 */
> >
> > #define GPIO_SDMMC2_D2   GPIO_SDMMC2_D2_1  /* PG11 FC_PG11_SDMMC2_D2 */
> >
> > //  GPIO_SDMMC2_D3No Remap /* PB4  FC_PB4_SDMMC2_D3  */
> >
> > is:
> >
> > #define GPIO_SDMMC2_CK   (GPIO_SDMMC2_CK_1|  GPIO_SPEED_25MHz)  /*
> > PD6  FC_PD6_SDMMC2_CK  */
> >
> > #define GPIO_SDMMC2_CMD  (GPIO_SDMMC2_CM