Build failed in Jenkins: NuttX-Nightly-Build #153

See Changes: -- [...truncated 212.59 KB...] Copy files Select CONFIG_HOST_LINUX=y Refreshing... Disabling CONFIG_ARMV7M_TOOLCHAIN_GNU_EABIL Enabling CONFIG_ARMV7M_TOOLCHAIN_

Re: Release Notes for the NEXT version of NuttX

On Thu, May 14, 2020 at 11:07 PM Abdelatif Guettouche wrote: > > That looks good. > Just one small thing: Is your board in-tree with other STM32s? > I'm asking because the referenced commit didn't make the change to the > build system, it re-organized the STM32 boards. The "real" change to > the

Re: Release Notes for the NEXT version of NuttX

That looks good. Just one small thing: Is your board in-tree with other STM32s? I'm asking because the referenced commit didn't make the change to the build system, it re-organized the STM32 boards. The "real" change to the build system was made in a previous release (8.2?) when Alin and Greg re-o

Re: Release Notes for the NEXT version of NuttX

On Thu, May 14, 2020 at 6:40 PM Abdelatif Guettouche wrote: > I noted one thing: > "Rename src/Makefile to src/Make.defs" > I'm not sure about this one, this applies only if the board family > uses a common directory (like CXD56 does and recently STM32). > The "Makefile" way still works and is sti

Re: QSPI on STM32F7

Maybe because you sent it as .patch, you need to rename it to .txt. This is an old issue we still facing... On 5/14/20, Joao Matos wrote: > Sorry for the late reply. > > Dunno why the patches are not showing up, they show up as attached on my > email client. > > Here goes in Gist format: > https

Re: Release Notes for the NEXT version of NuttX

Thank you for this initiative, this will make preparing release notes much easier. I noted one thing: "Rename src/Makefile to src/Make.defs" I'm not sure about this one, this applies only if the board family uses a common directory (like CXD56 does and recently STM32). The "Makefile" way still wor

Release Notes for the NEXT version of NuttX

After the release of NuttX-9.0, there have been some build system changes that starting with NuttX-9.1 will likely break custom board configurations that people might have. While the information is fresh in my head, I went ahead and created on Confluence a page to start working on our next Release

Re: QSPI on STM32F7

Sorry for the late reply. Dunno why the patches are not showing up, they show up as attached on my email client. Here goes in Gist format: https://gist.github.com/tritao/406dc1460a9df6788ce2823d300be7a7 On Tue, May 5, 2020 at 4:09 PM Rob Voisey wrote: > Actually it was my fault, I'm on a sligh

Re: Adding support for STM32G474RET6

BIG UPDATE: The board boots NuttX to a working NSH prompt! This means that a whole lot of things went right. It is now time to open a PR and start the review process. I'm going to title the PR [DO NOT MERGE] until we go through it... Greg, thanks for your help. David and Alan, thanks for volunt

RE: Compilation paths

I can answer myself after doing some more general research: It's related to dereference of symbolic links when changing the working directory. As it can be seen in below message (objdump output), the working directory during compilation of the chip stuff is "arch/arm/src" which means the "chip"

Compilation paths

Hello, Just a short question because of a lack of understanding: During make process there are symlinks created: For an ARM target at least "arch/arm/src/chip" and "arch/arm/src/board". What I don't understand: Why is the chip stuff compiled in the virtual folder, but the board stuff is compiled