Re: SAMA5D27 SDMMC support branch

No, In addition to the board-specific parts you implemented, we need to port the code of nuttx/arch/arm/src/cxd56xx/cxd56_sdhci.c or nuttx/arch/arm/src/imxrt/imxrt_usdhc.c to sama5d2. On 2020/03/07 15:15, Adam Feuer wrote: This one? https://github.com/apache/incubator-nuttx/blob/master/board

Re: SAMA5D27 SDMMC support branch

This one? https://github.com/apache/incubator-nuttx/blob/master/boards/arm/cxd56xx/spresense/src/cxd56_sdcard.c On Fri, Mar 6, 2020 at 21:42 Adam Feuer wrote: > Do those have NuttX implementations? If so will you point me at them? > > -adam > > On Fri, Mar 6, 2020 at 21:40 Takeyoshi Kikuchi >

Re: SAMA5D27 SDMMC support branch

Do those have NuttX implementations? If so will you point me at them? -adam On Fri, Mar 6, 2020 at 21:40 Takeyoshi Kikuchi wrote: > Adam, > > Since the SDMMC controller of the SAMA5D2 series is compatible with the > standard register set, I think it is better to port the implementation > of SON

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

See Changes: -- [...truncated 553.04 KB...] net_ipv4addr_hdrcopy(ipv4->srcipaddr, &dev->d_ipaddr); ^~~~ tcp/tcp_send.c:336:7: warning: dereferencing type-

Re: SAMA5D27 SDMMC support branch

Adam, Since the SDMMC controller of the SAMA5D2 series is compatible with the standard register set, I think it is better to port the implementation of SONY CXD56xx or NXP i.MXRT. Takeyoshi Kikuchi On 2020/03/07 9:29, Adam Feuer wrote: Takeyoshi, I started a branch for SAMA5D27 SDMMC support,

Re: Apache 2.0 License headers in source files

Thanks Greg and Justin. I read the page that Justin linked to— that was helpful. cheers adam On Fri, Mar 6, 2020 at 7:30 PM Justin Mclean wrote: > Hi, > > Your cannot change the license header without the owners permission and > it’s ASF policy to not change any copyright notices without permis

Re: Apache 2.0 License headers in source files

Hi, Your cannot change the license header without the owners permission and it’s ASF policy to not change any copyright notices without permission. Greg has given his permission via a software grant but there is still a large amount of 3rd party code in the repo.. Is some cases existing files d

irony

irony *https://github.com/apache/incubator-nuttx/runs/491066405#step:5:11*

SAMA5D27 SDMMC support branch

Takeyoshi, I started a branch for SAMA5D27 SDMMC support, it's here: https://github.com/starcat-io/incubator-nuttx/tree/feature/sama5d27-sdmmc-support I just started it, so not much progress, but I'll let you know if I get any further. -adam -- Adam Feuer

Re: Apache 2.0 License headers in source files

We have to be careful with copyrights on the files.  I have provided a software grant to the ASF and have agreed to change the license to Apache 2.0 for all of the files for which I am the sole copyright holder.  So I think that those code be changed (provided that there are no other caveats in

Apache 2.0 License headers in source files

Hi, To comply with NuttX coding style in a recent PR, I modified a file license header tool to easily replace license headers in NuttX code. Here's the PR I used it on: https://github.com/apache/incubator-nuttx/pull/449 Here's the tool, the modifications are currently on this branch: https://g

[GitHub] [incubator-nuttx-testing] liuguo09 commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container

liuguo09 commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container URL: https://github.com/apache/incubator-nuttx-testing/pull/13#issuecomment-596034731 > @liuguo09 I'll make some detailed comments tonight. Including the multistage image which will resol

[GitHub] [incubator-nuttx-testing] liuguo09 commented on a change in pull request #13: docker: initial checkin Dockerfile for nuttx github action container

liuguo09 commented on a change in pull request #13: docker: initial checkin Dockerfile for nuttx github action container URL: https://github.com/apache/incubator-nuttx-testing/pull/13#discussion_r389218688 ## File path: docker/Dockerfile ## @@ -0,0 +1,34 @@ +FROM ubuntu:1

[GitHub] [incubator-nuttx-testing] liuguo09 commented on a change in pull request #13: docker: initial checkin Dockerfile for nuttx github action container

liuguo09 commented on a change in pull request #13: docker: initial checkin Dockerfile for nuttx github action container URL: https://github.com/apache/incubator-nuttx-testing/pull/13#discussion_r389218702 ## File path: docker/Dockerfile ## @@ -0,0 +1,34 @@ +FROM ubuntu:1

Re: Build failed in Jenkins: NuttX-Nightly-Build #55

The arch/arm/src/sama5/hardware/_sama5d3x_memorymap.h update in commit 730133d84a62b77ced3f54478ca2f470c0364c0d "SAMA5D27 peripheral support - USB Host working (#444)" make the following config build break. Conf

[GitHub] [incubator-nuttx-testing] btashton commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container

btashton commented on issue #13: docker: initial checkin Dockerfile for nuttx github action container URL: https://github.com/apache/incubator-nuttx-testing/pull/13#issuecomment-595823686 @liuguo09 I'll make some detailed comments tonight. Including the multistage image which will resolve

Re: squashing commits or not

I think you made it clear that you prefer a TL;DR; document. Maybe we can have both. But I don't see what best practices that link shows, it's basically a shrinked version of what we already have (minus the submodule stuff). >> ...not hundreds of useless emails saying merged prxyz! >> >> We need

RE: squashing commits or not

> I see your point, however I do not think the overwhelming feeling is real enough for the folks the contributed to the document. Now that we really see a how small (and painful submitting) the patch to PR ratio can we not focus on the past not "best practices" and document a real work flow? Her

RE: stm32h7 support for SDRAM via FMC

Andrew, My apologies! Bitbucket is a legacy mirror. Greg can you put a Notice on the site to avoid this sort of thing. Please submit a PR on Github https://github.com/apache/incubator-nuttx https://github.com/apache/incubator-nuttx-apps David -Original Message- From: Заболотный Андре

Re: [PATCH] arch/arm/src/stm32l4/stm32l4_iwdg.c: do not unconditionally enable debug bits

Merged.. Thanks, Greg

Re: SAMA5D2 SDMMC support?

I think the SAMA5D2 has a different MMC controller from the D3 and D4. The D2 has SDMMC, I think the D3 and D4 have HSMCI. There's code in the Atmel software package repo for both, but SDMMC I couldn't find it in NuttX. You would have to compare the register offsets and bit definitions to kn

Re: RTC Periodic interrupt issue

Hi Anjana, On quick code reading, I think you are right. We have only used RTC_SET_PERIODIC and RTC_CANCEL_PERIODIC in pairs and as a third alarm so have not noticed this before. Could you please submit a patch or PR when satisfied with your testing. Best Regards, Juha _

RTC Periodic interrupt issue

Hello Team, We were testing periodic interrupt for RX65N, and observed that in function rtc_periodic_callback() in rtc.c file, alarminfo->active = false; As per my understanding, alarminfo->active = false;, this will kill the signal, which will disable the interrupt. In effect, periodic interr

stm32h7 support for SDRAM via FMC

Hello developers! I have added support for SDRAM initialization and registration with system heap to the FMC driver on stm32h7 family. I would like to submit these changes to mainline NuttX. The respective git branch is here: https://bitbucket.org/zapparello/nuttx/branch/stm32h7-fmc The branch

Re: squashing commits or not

> Thank you. The link did not lad me and I have no idea what to look at there > among the 10,404 words... I see your point, however, the steps (and git commands) are all in one place with the necessary explanations. If one decides not to read anything but the commands, they are highlighted with c

[PATCH] arch/arm/src/stm32l4/stm32l4_iwdg.c: do not unconditionally enable debug bits

The DBGMCU_APB1_FZ bit persists over regular software resets until next POR-reset. It can impact device power consumption and things that persist over resets are a bane for FOTA updates so make it disabled by default. OpenOCD sets this via DAP when connecting to target so enabling this from Kconfi