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

See Changes: -- [...truncated 295.32 KB...] Configuration/Tool: sim/sixlowpan

Re: Adding support for STM32G474RET6

On Fri, Apr 17, 2020 at 12:04 PM Xiang Xiao wrote: > > On Fri, Apr 17, 2020 at 11:17 AM Nathan Hartman > wrote: > > > > On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao > > wrote: > > > > > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane > > > wrote: > > > > > > > > Thank you for fixing the typos. I

Re: Adding support for STM32G474RET6

On Fri, Apr 17, 2020 at 11:17 AM Nathan Hartman wrote: > > On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao > wrote: > > > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane > > wrote: > > > > > > Thank you for fixing the typos. I am sure I can make them faster than you > > > can fix them. :) > > > > > >

Re: Adding support for STM32G474RET6

On Thu, Apr 16, 2020 at 10:47 PM Xiang Xiao wrote: > On Fri, Apr 17, 2020 at 5:54 AM David Sidrane > wrote: > > > > Thank you for fixing the typos. I am sure I can make them faster than you > > can fix them. :) > > > > Actually, checkpatch.sh support -c option which do the spell check by >

Re: Adding support for STM32G474RET6

On Fri, Apr 17, 2020 at 5:54 AM David Sidrane wrote: > > Thank you for fixing the typos. I am sure I can make them faster than you > can fix them. :) > Actually, checkpatch.sh support -c option which do the spell check by invoke codespell(the same tool used by Linux):

Re: [PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and check malloc return values

Juha, Since you contribute many code to NuttX and work with NuttX daily, it will be more efficient and collaborative if you can send the patch through github PR. Thanks Xiang On Thu, Apr 16, 2020 at 8:53 PM Alan Carvalho de Assis wrote: > > Hi Juha, > > I just created apps PR #183 with your

RE: Adding support for STM32G474RET6

Thank you for fixing the typos. I am sure I can make them faster than you can fix them. :) I started to lean heavier on the side of Kconfig. You should know historically, there was a pre Kconfig time, so this is an organic trajectory. The dividing lines for me are invariant vs variant and user

Re: Test jobs failing due to timeouts?

This is an issue with GitHub unfortunately and got worse recently. I'll make some changes to the job that should help make this more robust later this week. On Thu, Apr 16, 2020, 12:26 PM Nathan Hartman wrote: > In my PRs I seem to get a lot of test failures, and I have to re-run > the tests,

Re: Adding support for STM32G474RET6

On Thu, Apr 16, 2020 at 1:00 PM David Sidrane wrote: > If you look at the Kinetis, > https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 > > You can see the gist of that approach. > > It idea was as developers on the outside of the MFG, we only see

Test jobs failing due to timeouts?

In my PRs I seem to get a lot of test failures, and I have to re-run the tests, because of: [[[ Unable to find image 'docker.pkg.github.com/apache/incubator-nuttx-testing/nuttx-ci-linux:latest' locally /usr/bin/docker: Error response from daemon: Get https://docker.pkg.github.com/v2/: net/http:

RE: Adding support for STM32G474RET6

Nathan, If you look at the Kinetis, https://github.com/apache/incubator-nuttx/blob/master/arch/arm/include/kinetis/kinetis_pmc.h#L50-L63 You can see the gist of that approach. It idea was as developers on the outside of the MFG, we only see the deltas in datasheets. We do not know, the feature

Re: Adding support for STM32G474RET6

On Thu, Apr 16, 2020 at 10:41 AM Gregory Nutt wrote: > One thing you can do to keep prevent the runaway dependencies on > specific chips is to parameterized the features. For example, if > STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of > conditioning the implementation of

Re: Adding support for STM32G474RET6

One thing you can do to keep prevent the runaway dependencies on specific chips is to parameterized the features.  For example, if STM32abc, STM32def, and STM32ghi and have FEATURE_X, then instead of conditioning the implementation of FEATURE_X on all of those MCUs, you could minimize the

Re: Adding support for STM32G474RET6

So what's the deciding factor? Should this be in 'stm32' directory because most peripherals have compatibility? Or a different directory because RCC is different? The deciding factor should be maintainability. I have not heard any reason why the support should not go under stm32/.  Mu only

Re: Adding support for STM32G474RET6

On Thu, Apr 16, 2020 at 1:16 AM raiden00pl . wrote: > > How does the RCC (clock tree) compare? > > RCC looks like in G0 family, which is not registers compatible with older > versions. But clock tree is similar to those found in F4/F7. On Thu, Apr 16, 2020 at 12:44 AM raiden00pl . wrote: > Yes,

Re: [PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and check malloc return values

Hi Juha, I just created apps PR #183 with your patch. Thank you! BR, Alan On 4/16/20, Juha Niskanen (Haltian) wrote: > Hi, > > Small thing I found when reading through nsh code. > > Best Regards, >Juha >

[PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and check malloc return values

Hi, Small thing I found when reading through nsh code. Best Regards, Juha From 16c0929da29f38057d42c72219afe7d86aa19962 Mon Sep 17 00:00:00 2001 From: Juha Niskanen Date: Thu, 16 Apr 2020 13:36:21 +0300 Subject: [PATCH] nshlib/nsh_codeccmd.c: fix potential NULL dereference and check malloc