Re: [Article] Your very own Build Farm for NuttX
Hi Lup, Again, thanks for the amazing work on CI! I'm planning to provide a PC for the build farm too. I've read your articles about it, but it isn't clear how should I proceed after uploading the gists to my github account. Should I run the scrapping myself with https://github.com/lupyuen/ingest-nuttx-builds or do you take control of it as soon as I provide the gists? Am I missing something in the articles? Best regards, Em ter., 29 de out. de 2024 às 15:43, Alan C. Assis escreveu: > Alin, maybe we need to add READONLY in the ldscript: > > > https://stackoverflow.com/questions/73429929/gnu-linker-elf-has-a-load-segment-with-rwx-permissions-embedded-arm-project > > BR, > > Alan > > On Mon, Oct 28, 2024 at 5:42 AM Alin Jerpelea wrote: > > > Hi all, > > > > is anyone aware of this warning ? > > riscv-none-elf-ld: warning: /nuttx/nuttx has a LOAD segment with RWX > > permissions > > > > Best regards > > Alin > > > > On Mon, Oct 28, 2024 at 9:31 AM Alin Jerpelea > wrote: > > > > > Hi Lup, > > > > > > I think that we all should push the logs as they are on > > > https://gist.github.com/nuttxpr in separate folders containing > > > build target (ex: arm-01) with logs renamed : platform_buildtime.log > > > or > > > platform/board/config with logs renamed > > > : platform_board_config_buildtime.log > > > > > > This should simplify the scripting and display > > > > > > what so you think ? > > > > > > On Mon, Oct 28, 2024 at 9:25 AM Lee, Lup Yuen > wrote: > > > > > >> << the results from my test are available on > > >> https://gist.github.com/jerpelea >> > > >> > > >> That's awesome Alin, thanks! :-) > > >> > > >> << I think that we should push all results on a git with date sorted > by > > >> platform /board then create a simple heatmap with the latest build and > > >> green/red >> > > >> > > >> Yep lemme figure out if open-source Grafana can do this (with some > > >> scripting): https://grafana.com/oss/grafana/ > > >> > > >> Lup > > >> > > >> On Mon, Oct 28, 2024 at 4:22 PM Alin Jerpelea > > wrote: > > >> > > >> > HI all > > >> > the results from my test are available on > > >> https://gist.github.com/jerpelea > > >> > > > >> > I think that we should push all results on a git with date sorted by > > >> > platform /board then create a simple heatmap with the latest build > and > > >> > green/red > > >> > @lup what do you think ? > > >> > > > >> > > > >> > Best regards > > >> > Alin > > >> > > > >> > On Mon, Oct 28, 2024 at 9:15 AM Alin Jerpelea > > >> wrote: > > >> > > > >> > > Hi Lup, > > >> > > > > >> > > please add to the guide > > >> > > "gh auth login" so that users can upload the results > > >> > > > > >> > > Best regards > > >> > > Alin > > >> > > > > >> > > > > >> > > On Mon, Oct 28, 2024 at 9:12 AM Lee, Lup Yuen > > >> wrote: > > >> > > > > >> > >> << please add to the guide "apt install gh " on host os >> > > >> > >> > > >> > >> Yep thanks Alin! I have updated the article: > > >> > >> > > >> > >> > > >> > > > >> > > > https://lupyuen.codeberg.page/articles/ci2.html#build-nuttx-for-all-target-groups > > >> > >> > > >> > >> ## Download the scriptsgit clone > > >> > >> https://github.com/lupyuen/nuttx-releasecd nuttx-release > > >> > >> ## Login to GitHub in Headless Modesudo apt install ghsudo gh > auth > > >> login > > >> > >> ## Run the Build Job forever: arm-01 ... arm-14sudo ./run-ci.sh > > >> > >> > > >> > >> > > >> > >> Lup > > >> > >> > > >> > >> On Mon, Oct 28, 2024 at 4:05 PM Alin Jerpelea < > jerpe...@gmail.com> > > >> > wrote: > > >> > >> > > >> > >> > Hi Lup > > >> > >> > > > >> > >> > please add to the guide > > >> > >> > "apt install gh " > > >> > >> > on host os > > >> > >> > > > >> > >> > Best regards > > >> > >> > Alin > > >> > >> > > > >> > >> > On Mon, Oct 28, 2024 at 8:50 AM Lee, Lup Yuen < > lu...@appkaki.com > > > > > >> > >> wrote: > > >> > >> > > > >> > >> > > Thanks Alin, I think the fix is here: > > >> > >> > > https://github.com/apache/nuttx/pull/14527 > > >> > >> > > > > >> > >> > > Lup > > >> > >> > > > > >> > >> > > On Mon, Oct 28, 2024 at 3:43 PM Alin Jerpelea < > > >> jerpe...@gmail.com> > > >> > >> > wrote: > > >> > >> > > > > >> > >> > > > Cmake in present: > > >> stm32f334-disco/nsh,CONFIG_ARM_TOOLCHAIN_CLANG > > >> > >> > > > Configuration/Tool: > > >> stm32f334-disco/nsh,CONFIG_ARM_TOOLCHAIN_CLANG > > >> > >> > > > 2024-10-28 07:41:50 > > >> > >> > > > > > >> > >> > > > > > >> > >> > > > > >> > >> > > > >> > >> > > >> > > > >> > > > > > >> > >> > > > Cleaning... > > >> > >> > > > Configuring... > > >> > >> > > > CMake Warning at cmake/nuttx_kconfig.cmake:171 (message): > > >> > >> > > > Kconfig Configuration Error: warning: > > >> STM32_HAVE_HRTIM1_PLLCLK > > >> > >> > (defined > > >> > >> > > > at > > >> > >> > > > arch/arm/src/stm32/Kconfig:8109) has direct dependencies > > >> > >> STM32_HRTIM > > >> > >> > && > > >> > >> > > > ARCH_CHIP_STM32 && ARCH_ARM with val
RP2040 clock speed increase
Hello everyone, Recently the RP2040 has officially been rated up to 200MHz by Raspberry Pi, a bump from the 125MHz speeds it was initially rated for. It appears the Pico SDK has been updated recently to allow users to use the new rated speed. Here's an interesting conversation about the topic on the Arduino project: https://github.com/earlephilhower/arduino-pico/issues/2814 I think we should discuss the same thing here for NuttX. Should we update the RP2040 to now use 200MHz as the default, since that is its rated speed? And we should then update the version of the Pico SDK mentioned in our documentation so that users can leverage the new clock speed. I would propose that at the same time we update that in the documentation, we perhaps include the installation/build procedure for the SDK and picotool on a common doc page (the RP2040 chip page) so that we don't need to update every single RP2040 board page with the new version when we upgrade on the NuttX side. That way each board page can simply link to the installation procedure (afaik none of them have a different procedure). Regards, -- Matteo Golin signature.asc Description: PGP signature
Re: [Article] Your very own Build Farm for NuttX
Thanks Tiago! Just tell me your GitHub Gist ID (or GitLab Snippet ID). I'll add it to ingest-nuttx-builds, which runs non-stop on my computer: https://github.com/lupyuen/ingest-nuttx-builds/blob/main/run.sh We can chat more in this NuttX Issue. Thanks :-) https://github.com/apache/nuttx/issues/14558 Lup On Sat, Feb 22, 2025 at 3:42 AM Tiago Medicci Serrano < tiago.medi...@gmail.com> wrote: > Hi Lup, > > Again, thanks for the amazing work on CI! I'm planning to provide a PC for > the build farm too. > > I've read your articles about it, but it isn't clear how should I proceed > after uploading the gists to my github account. Should I run the scrapping > myself with https://github.com/lupyuen/ingest-nuttx-builds or do you take > control of it as soon as I provide the gists? > > Am I missing something in the articles? > > Best regards, > > Em ter., 29 de out. de 2024 às 15:43, Alan C. Assis > escreveu: > > > Alin, maybe we need to add READONLY in the ldscript: > > > > > > > https://stackoverflow.com/questions/73429929/gnu-linker-elf-has-a-load-segment-with-rwx-permissions-embedded-arm-project > > > > BR, > > > > Alan > > > > On Mon, Oct 28, 2024 at 5:42 AM Alin Jerpelea > wrote: > > > > > Hi all, > > > > > > is anyone aware of this warning ? > > > riscv-none-elf-ld: warning: /nuttx/nuttx has a LOAD segment with RWX > > > permissions > > > > > > Best regards > > > Alin > > > > > > On Mon, Oct 28, 2024 at 9:31 AM Alin Jerpelea > > wrote: > > > > > > > Hi Lup, > > > > > > > > I think that we all should push the logs as they are on > > > > https://gist.github.com/nuttxpr in separate folders containing > > > > build target (ex: arm-01) with logs renamed : platform_buildtime.log > > > > or > > > > platform/board/config with logs renamed > > > > : platform_board_config_buildtime.log > > > > > > > > This should simplify the scripting and display > > > > > > > > what so you think ? > > > > > > > > On Mon, Oct 28, 2024 at 9:25 AM Lee, Lup Yuen > > wrote: > > > > > > > >> << the results from my test are available on > > > >> https://gist.github.com/jerpelea >> > > > >> > > > >> That's awesome Alin, thanks! :-) > > > >> > > > >> << I think that we should push all results on a git with date sorted > > by > > > >> platform /board then create a simple heatmap with the latest build > and > > > >> green/red >> > > > >> > > > >> Yep lemme figure out if open-source Grafana can do this (with some > > > >> scripting): https://grafana.com/oss/grafana/ > > > >> > > > >> Lup > > > >> > > > >> On Mon, Oct 28, 2024 at 4:22 PM Alin Jerpelea > > > wrote: > > > >> > > > >> > HI all > > > >> > the results from my test are available on > > > >> https://gist.github.com/jerpelea > > > >> > > > > >> > I think that we should push all results on a git with date sorted > by > > > >> > platform /board then create a simple heatmap with the latest build > > and > > > >> > green/red > > > >> > @lup what do you think ? > > > >> > > > > >> > > > > >> > Best regards > > > >> > Alin > > > >> > > > > >> > On Mon, Oct 28, 2024 at 9:15 AM Alin Jerpelea > > > > >> wrote: > > > >> > > > > >> > > Hi Lup, > > > >> > > > > > >> > > please add to the guide > > > >> > > "gh auth login" so that users can upload the results > > > >> > > > > > >> > > Best regards > > > >> > > Alin > > > >> > > > > > >> > > > > > >> > > On Mon, Oct 28, 2024 at 9:12 AM Lee, Lup Yuen < > lu...@appkaki.com> > > > >> wrote: > > > >> > > > > > >> > >> << please add to the guide "apt install gh " on host os >> > > > >> > >> > > > >> > >> Yep thanks Alin! I have updated the article: > > > >> > >> > > > >> > >> > > > >> > > > > >> > > > > > > https://lupyuen.codeberg.page/articles/ci2.html#build-nuttx-for-all-target-groups > > > >> > >> > > > >> > >> ## Download the scriptsgit clone > > > >> > >> https://github.com/lupyuen/nuttx-releasecd nuttx-release > > > >> > >> ## Login to GitHub in Headless Modesudo apt install ghsudo gh > > auth > > > >> login > > > >> > >> ## Run the Build Job forever: arm-01 ... arm-14sudo ./run-ci.sh > > > >> > >> > > > >> > >> > > > >> > >> Lup > > > >> > >> > > > >> > >> On Mon, Oct 28, 2024 at 4:05 PM Alin Jerpelea < > > jerpe...@gmail.com> > > > >> > wrote: > > > >> > >> > > > >> > >> > Hi Lup > > > >> > >> > > > > >> > >> > please add to the guide > > > >> > >> > "apt install gh " > > > >> > >> > on host os > > > >> > >> > > > > >> > >> > Best regards > > > >> > >> > Alin > > > >> > >> > > > > >> > >> > On Mon, Oct 28, 2024 at 8:50 AM Lee, Lup Yuen < > > lu...@appkaki.com > > > > > > > >> > >> wrote: > > > >> > >> > > > > >> > >> > > Thanks Alin, I think the fix is here: > > > >> > >> > > https://github.com/apache/nuttx/pull/14527 > > > >> > >> > > > > > >> > >> > > Lup > > > >> > >> > > > > > >> > >> > > On Mon, Oct 28, 2024 at 3:43 PM Alin Jerpelea < > > > >> jerpe...@gmail.com> > > > >> > >> > wrote: > > > >> > >> > > > > > >> > >> > > > Cmake in present: > > > >> stm32f334-disco/nsh,CONFIG_ARM_TOOLCHAIN_CLANG > > > >> > >> > > > Configuration/Too
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Hi all! About the pending proposals, can we proceed to another vote round? I think we should wrap up it subject and create the article in the docs as soon as possible... Are we waiting for something else? Best regards, Em ter., 18 de fev. de 2025 às 09:45, Tiago Medicci Serrano < tiago.medi...@gmail.com> escreveu: > Hi! > > So is it okay to keep 2 reviewers for version bumps and documentation >> updates and 4 for the rest? Maybe its good to have two rules: 2 >> reviews for trivial updates like version bumps and documentation >> update (what else?) and 4 reviews for all other PRs? > > > IMHO, It's still too restrictive. I liked the concept of having these 4 > major areas: > * Under Development: 1 reviewer > * Experimental: 1 reviewer (eventually 2 if breaking changes) > * Production Stable: 4 reviewers (in case of breaking changes, still valid > the rule for discussing in the mailing list) > * Periphery: 1 reviewer > > Best regards, > > Em seg., 17 de fev. de 2025 às 19:15, Tomek CEDRO > escreveu: > >> On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano >> wrote: >> > Hi! >> > Thanks, Tomek, for summarizing it. >> > >> > I liked Nathan's proposal. Instead of simply increasing the number of >> > reviewers from 2 to 4, we can adopt tags (we can even evaluate if the >> bot >> > can do it automatically), and, based on such categories, we have new >> > requirements for the reviewers. >> > >> > Considering that, I'd drop the concept of *Lazy Consensus* (item 19) >> > because it covers my main concern: >> > >> > We *should* try to keep NuttX as stable and backwards compatible as >> > > feasible so that people can adopt NuttX and count on it to keep >> > > working for them in the long run. >> > > At the same time, >> > > >> > > *we need to be very careful not to make rules thatare too strict and >> > > inflexible, because then we would risk turning awaycontributors and we >> > > would end up with old cruft that is really brokenand generating a lot >> of >> > > complaints but can't be fixed because it wouldbreak the rules.* >> > > So we need to strike a good balance. >> > >> > We don't need a general rule and 4 reviewers for Documentation and new >> chip >> > bring-ups. We need 4 (or even more) reviewers for changes that break >> > production-ready interfaces. >> >> Yeah I just wanted rules to be as simple as possible and generic that >> would avoid exceptions. If exceptions are required then maybe another >> simple rule should be added? The problem is we don't really know what >> change will break what and lots of PRs had testing section as short as >> "CI" nothing more :-P >> >> So is it okay to keep 2 reviewers for version bumps and documentation >> updates and 4 for the rest? Maybe its good to have two rules: 2 >> reviews for trivial updates like version bumps and documentation >> update (what else?) and 4 reviews for all other PRs? >> >> Thanks! :-) >> Tomek >> >> -- >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >> >
Re: [VOTE] NuttX Contributing Guidelines update 202502.
Thank you Tiago! I have prepared a google form with all questions 1-19 updated based on our discussions, I will post it now as separate thread so it is not missed, hopefully this way will help in results gathering and presentation and there are optional fields where anyone can propose better texting and/or rules update if the do not agree :-) Tomek On Fri, Feb 21, 2025 at 5:56 PM Tiago Medicci Serrano wrote: > > Hi all! > > About the pending proposals, can we proceed to another vote round? > > I think we should wrap up it subject and create the article in the docs as > soon as possible... > > Are we waiting for something else? > > Best regards, > > Em ter., 18 de fev. de 2025 às 09:45, Tiago Medicci Serrano < > tiago.medi...@gmail.com> escreveu: > > > Hi! > > > > So is it okay to keep 2 reviewers for version bumps and documentation > >> updates and 4 for the rest? Maybe its good to have two rules: 2 > >> reviews for trivial updates like version bumps and documentation > >> update (what else?) and 4 reviews for all other PRs? > > > > > > IMHO, It's still too restrictive. I liked the concept of having these 4 > > major areas: > > * Under Development: 1 reviewer > > * Experimental: 1 reviewer (eventually 2 if breaking changes) > > * Production Stable: 4 reviewers (in case of breaking changes, still valid > > the rule for discussing in the mailing list) > > * Periphery: 1 reviewer > > > > Best regards, > > > > Em seg., 17 de fev. de 2025 às 19:15, Tomek CEDRO > > escreveu: > > > >> On Mon, Feb 17, 2025 at 12:20 PM Tiago Medicci Serrano > >> wrote: > >> > Hi! > >> > Thanks, Tomek, for summarizing it. > >> > > >> > I liked Nathan's proposal. Instead of simply increasing the number of > >> > reviewers from 2 to 4, we can adopt tags (we can even evaluate if the > >> bot > >> > can do it automatically), and, based on such categories, we have new > >> > requirements for the reviewers. > >> > > >> > Considering that, I'd drop the concept of *Lazy Consensus* (item 19) > >> > because it covers my main concern: > >> > > >> > We *should* try to keep NuttX as stable and backwards compatible as > >> > > feasible so that people can adopt NuttX and count on it to keep > >> > > working for them in the long run. > >> > > At the same time, > >> > > > >> > > *we need to be very careful not to make rules thatare too strict and > >> > > inflexible, because then we would risk turning awaycontributors and we > >> > > would end up with old cruft that is really brokenand generating a lot > >> of > >> > > complaints but can't be fixed because it wouldbreak the rules.* > >> > > So we need to strike a good balance. > >> > > >> > We don't need a general rule and 4 reviewers for Documentation and new > >> chip > >> > bring-ups. We need 4 (or even more) reviewers for changes that break > >> > production-ready interfaces. > >> > >> Yeah I just wanted rules to be as simple as possible and generic that > >> would avoid exceptions. If exceptions are required then maybe another > >> simple rule should be added? The problem is we don't really know what > >> change will break what and lots of PRs had testing section as short as > >> "CI" nothing more :-P > >> > >> So is it okay to keep 2 reviewers for version bumps and documentation > >> updates and 4 for the rest? Maybe its good to have two rules: 2 > >> reviews for trivial updates like version bumps and documentation > >> update (what else?) and 4 reviews for all other PRs? > >> > >> Thanks! :-) > >> Tomek > >> > >> -- > >> CeDeROM, SQ7MHZ, http://www.tomek.cedro.info > >> > > -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
[VOTE] ROUND2 NuttX Contributing Guidelines update 202502.
Hello world :-) After the first voting, discussions, and updates, here goes the Round 2 of the voting for NuttX Contributing Guidelines update: https://forms.gle/m3uRDGuE3QZy2yNn6 There are again all rule propositions numbered from 1 to 19 with optional text fields if you feel texting can be fixed, especially important to provide feedback when you vote 0 or -1. Vote will close on 20250228 with results presentation and hopefully rules update :-) Thank you for your time and votes! :-) Tomek -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: RP2040 clock speed increase
On Fri, Feb 21, 2025 at 7:53 PM Matteo Golin wrote: > Recently the RP2040 has officially been rated up to 200MHz by Raspberry Pi, a > bump from the 125MHz speeds it was > initially rated for. It appears the Pico SDK has been updated recently to > allow users to use the new rated speed. > > Here's an interesting conversation about the topic on the Arduino project: > https://github.com/earlephilhower/arduino-pico/issues/2814 > > I think we should discuss the same thing here for NuttX. Should we update the > RP2040 to now use 200MHz as the default, > since that is its rated speed? And we should then update the version of the > Pico SDK mentioned in our documentation so > that users can leverage the new clock speed. I would propose that at the same > time we update that in the documentation, > we perhaps include the installation/build procedure for the SDK and picotool > on a common doc page (the RP2040 chip page) > so that we don't need to update every single RP2040 board page with the new > version when we upgrade on the NuttX side. > That way each board page can simply link to the installation procedure (afaik > none of them have a different procedure). Good idea Matteo :-) I bought rPI-Pico(-W) and rpi-Pico-2(-W) 4 boards just for testing but I am not familiar with the hw :-) Would it be good to allow users to select clock frequency? If 125MHz -> 200MHz that would imply increased power consumption too? Can it be easily changed at runtime? -- CeDeROM, SQ7MHZ, http://www.tomek.cedro.info
Re: RP2040 clock speed increase
It appears this is selected at compile time using a #define in the SDK. I would certainly assume increased power consumption, however the Picos are definitely able to handle this increased consumption, as I would assume other boards are. I would say the approach would be no different than configuring the clock speed on an STM32, asides from not having to configure multiple sub-clocks and just changing one in the configuration. Personally I'm of the opinion that the highest rated clock speed should be the default, and users can turn it down if they require lower power consumption. I do not know how much of an increase in power is required for the speed increase, but I do know that the speed increase is rated for any board with >1.15V supply. On Fri, Feb 21, 2025, 10:12 PM Tomek CEDRO wrote: > On Fri, Feb 21, 2025 at 7:53 PM Matteo Golin > wrote: > > Recently the RP2040 has officially been rated up to 200MHz by Raspberry > Pi, a bump from the 125MHz speeds it was > > initially rated for. It appears the Pico SDK has been updated recently > to allow users to use the new rated speed. > > > > Here's an interesting conversation about the topic on the Arduino > project: > > https://github.com/earlephilhower/arduino-pico/issues/2814 > > > > I think we should discuss the same thing here for NuttX. Should we > update the RP2040 to now use 200MHz as the default, > > since that is its rated speed? And we should then update the version of > the Pico SDK mentioned in our documentation so > > that users can leverage the new clock speed. I would propose that at the > same time we update that in the documentation, > > we perhaps include the installation/build procedure for the SDK and > picotool on a common doc page (the RP2040 chip page) > > so that we don't need to update every single RP2040 board page with the > new version when we upgrade on the NuttX side. > > That way each board page can simply link to the installation procedure > (afaik none of them have a different procedure). > > Good idea Matteo :-) I bought rPI-Pico(-W) and rpi-Pico-2(-W) 4 boards > just for testing but I am not familiar with the hw :-) > > Would it be good to allow users to select clock frequency? If 125MHz > -> 200MHz that would imply increased power consumption too? Can it be > easily changed at runtime? > > -- > CeDeROM, SQ7MHZ, http://www.tomek.cedro.info >
