Re: Imxrt 1050

[Embedded Systems]

Hello Dave,

Thank you very much for the information. I will also keep an eye if i see
something in that direction!

Best regards,
Ivan Ucherdzhiev

On Tue, Jan 28, 2020 at 12:55 AM Dave Marples  wrote:

>
> On 07/01/2020 13:42, Embedded Systems wrote:
> > Hello,
> >
> > I found what is cousin that behaviour it is the WFI instruction in the
> idle
> > task. Please excuse me for bothering you.
>
>
> Ivan,
>
> This does not happen when programming imxrt in other environments (e.g.
> Zephyr, FreeRTOS) and is a concern to me since it implies there's a
> clock not switched on properly somewhere. We had this problem with the
> tick timer not interrupting when WFI was first (re-)enabled but that one
> was fixed. Chances are there's another bit hidden in one of the GPR
> registers controlling this. I'm back now so will investigate...just 2000
> emails to catch up with first.
>
> Regards
>
> DAVE
>
>
>

-- 
Kind regards,
Ivan Ucherdzhiev

Team Lead @ Barin Sports
Bulgaria
skype: ipy_44
tel: +359888927760

Re: [DISCUSS] Wrapping up the Workflow document

[Abdelatif Guettouche]

Hi David,

Are you assuming that the work is always on a same feature that you submit
PRs gradually?

The git usage looks off to me. It would be better to avoid deleting branches
> and using noises merge commits.
>
What are the cons of deleting branches?
What merge commits? I don't understand this last part, do you mean that the
procedure described in the workflow will generate merge commits?
Keeping a WIP branch in synch is missing from the workflow.
Basically same as you described, that should consist of synching master
(fetch + merge from upstream) then rebasing the branch on top of master.


On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
wrote:

> The git usage looks off to me. It would be better to avoid deleting
> branches
> and using noises merge commits.
>
>
> Assume the "upstream" remote is ASF repo
> Assume "prj" remote is my remote
> Assume your code is not in master on your fork.
>
> Submission:
>
> git push prj  master_my_branch
>
> open a PR on git hub (Fill out the template - we need one)
> ...
>
> Your PR comes into master: - this can be as is:no committer  modification
> or
> with modification by the committer.
>
> Reintegration
> Put your current work on top of latest master (with your contribution +
> others)
>
> git checkout master
> git fetch upstream
> git pull upstream master (it should only be a fast forward not merge
> commits) OR git reset --hard upstream/master (no question what you get)
> git checkout master_my_branch
> (optionally if PR codes was modified by committer  - to keep your work
> safe - git -b checkout master_my_branch_PR && git checkout
> master_my_branch)
> (optionally if PR codes was modified by committer  git reset --hard  is
> the parent of master_my_branch started>)
> git rebase master
>
> In reality if the PR was taken as is (no committer  modification) the
> rebase
> on master will only add others changes under your WIP.
>
>
> Alternate for backporting  - Cherry pick your work back to your fork.
>
> This workflow ensures your branch is equal in format to the upstream and no
> others changes. - This may be more stable.
> git checkout master
> git fetch upstream
> git pull upstream master OR git reset --hard upstream/master (no question
> what you get)
>
> git checkout master_my_branch
> git  -b checkout master_my_branch_PR && git checkout master_my_branch
> git reset --hard 
> git log master --oneline
> ^C
> git cherry-pick  ..
>
> add -e to change the commit message i.e add [BACKPORT]
>
> David
>
> -Original Message-
> From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
> Sent: Tuesday, January 28, 2020 8:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi Nathan,
>
> I reviewed the document and added some inlines comments (not sure if they
> are not recommended for use though).
>
> I haven't edited/added any text though, but I will be glad to help if
> needed.
>
> Cheers,
> Miguel
>
> On Fri, Jan 24, 2020 at 4:29 PM Nathan Hartman 
> wrote:
>
> > Hi all,
> >
> > The proposed Workflow document (see [1]) has a substantial amount of
> > good information in it.
> >
> > It is not yet 100% percent complete:
> > (1) There are several "REVISIT" notes throughout.
> > (2) A few sections toward the end aren't written yet.
> >
> > However, by the 80-20 rule, I think the most important parts have been
> > written, even if some things are rough around the edges.
> >
> > I have had a LOT of overtime at my $dayjob lately, which has kept me
> > from working much on NuttX. However, I don't want to let the workflow
> > fall by the wayside. I would like to get it wrapped up so we can vote
> > on it soon.
> >
> > Please, could we have some willing volunteers proofread the document,
> > fix some of the "REVISIT" parts, and help push this document that last
> > little bit to get it into a "shippable" state?
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
> > )
> >
> > Thanks,
> > Nathan
> >
>

[DISCUSS] Security list

[Flavio Junqueira]

This is Flavio, I'm one of the project mentors, and I'd like to start a 
discussion thread about creating a security list. Let me start with some 
background.

The ASF has a security team that provides guidance to projects on security 
matters and coordinates the handling of security vulnerabilities, e.g., 
handling CVE requests. The security team has a general secur...@apache.org 
address to receive reports and to communicate with projects. See this page for 
more information.

https://www.apache.org/security/ 

Some projects opt for having their own security team and consequently their own 
security list. Project security teams evaluate vulnerability reports submitted 
about the project and interact with both reporters and the Apache Security 
Team. 

If we create such a list for this project, then it would be listed here:

https://www.apache.org/security/projects.html 


And vulnerability reports would be sent to that list for evaluation. Without a 
project security list, any vulnerability report will be sent to the general 
secur...@apache.org list, which will then be forwarded to the private@nuttx 
list. 

In the case the team decides to have its own security team, the team includes 
project PMC members, and it could also include committers if the project 
chooses to. At this point of the project, there is no difference between the 
set of committers and PPMC, but it might make a difference later on.

The two points I suggest we discuss and eventually move to vote depending on 
the feedback are:

1- Should this project have a security team and create a 
secur...@nuttx.apache.org list for this project?
2- Should the security list include only project PMC members or also interested 
committers?

Thanks,
-Flavio

Re: NuttX at FOSDEM 2020

[Philippe Coval]

On Tue, Jan 28, 2020 at 9:02 PM Alan Carvalho de Assis 
wrote:

> Hi Brenan,
>
> Did you see it: https://fosdem.org/2020/scheduleshow caseshow
> case/event/iotnuttx/ 


Hi,

Yes I will walk through a PoC demo built on NuttX
and some other blocks on top of it...

Maybe I should have announced it in list earlier,
but I am glad that Alan did for me :)

Feel free to find me at FOSDEM,
Are others coming ?
may we arrange a meeting on saturday ?

I am RzR in IRC room

Regards

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif,

> Are you assuming that the work is always on a same feature that you submit
PRs gradually?

It can be but does not have to be.

> What are the cons of deleting branches?

Lost work. A botched commit by committer and you have nothing to compare it
to. branches are FREE.

> What merge commits?

I had seen a lot of PR that came into bitbucket in the past with many merge
commits from upstream. Rebasing avoids that.

(fetch + merge from upstream)
Should be fetch and or pull and should only result in a fast forward - with
many remotes I use git reset --hard  /master after a fetch.
Then as you say, I  rebase my wip on it.

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Tuesday, January 28, 2020 2:17 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

Hi David,

Are you assuming that the work is always on a same feature that you submit
PRs gradually?

The git usage looks off to me. It would be better to avoid deleting branches
> and using noises merge commits.
>
What are the cons of deleting branches?
What merge commits? I don't understand this last part, do you mean that the
procedure described in the workflow will generate merge commits?
Keeping a WIP branch in synch is missing from the workflow.
Basically same as you described, that should consist of synching master
(fetch + merge from upstream) then rebasing the branch on top of master.


On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
wrote:

> The git usage looks off to me. It would be better to avoid deleting
> branches
> and using noises merge commits.
>
>
> Assume the "upstream" remote is ASF repo
> Assume "prj" remote is my remote
> Assume your code is not in master on your fork.
>
> Submission:
>
> git push prj  master_my_branch
>
> open a PR on git hub (Fill out the template - we need one)
> ...
>
> Your PR comes into master: - this can be as is:no committer  modification
> or
> with modification by the committer.
>
> Reintegration
> Put your current work on top of latest master (with your contribution +
> others)
>
> git checkout master
> git fetch upstream
> git pull upstream master (it should only be a fast forward not merge
> commits) OR git reset --hard upstream/master (no question what you get)
> git checkout master_my_branch
> (optionally if PR codes was modified by committer  - to keep your work
> safe - git -b checkout master_my_branch_PR && git checkout
> master_my_branch)
> (optionally if PR codes was modified by committer  git reset --hard  is
> the parent of master_my_branch started>)
> git rebase master
>
> In reality if the PR was taken as is (no committer  modification) the
> rebase
> on master will only add others changes under your WIP.
>
>
> Alternate for backporting  - Cherry pick your work back to your fork.
>
> This workflow ensures your branch is equal in format to the upstream and
> no
> others changes. - This may be more stable.
> git checkout master
> git fetch upstream
> git pull upstream master OR git reset --hard upstream/master (no question
> what you get)
>
> git checkout master_my_branch
> git  -b checkout master_my_branch_PR && git checkout master_my_branch
> git reset --hard 
> git log master --oneline
> ^C
> git cherry-pick  ..
>
> add -e to change the commit message i.e add [BACKPORT]
>
> David
>
> -Original Message-
> From: Miguel Ángel Herranz [mailto:mig...@midokura.com.INVALID]
> Sent: Tuesday, January 28, 2020 8:49 AM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi Nathan,
>
> I reviewed the document and added some inlines comments (not sure if they
> are not recommended for use though).
>
> I haven't edited/added any text though, but I will be glad to help if
> needed.
>
> Cheers,
> Miguel
>
> On Fri, Jan 24, 2020 at 4:29 PM Nathan Hartman 
> wrote:
>
> > Hi all,
> >
> > The proposed Workflow document (see [1]) has a substantial amount of
> > good information in it.
> >
> > It is not yet 100% percent complete:
> > (1) There are several "REVISIT" notes throughout.
> > (2) A few sections toward the end aren't written yet.
> >
> > However, by the 80-20 rule, I think the most important parts have been
> > written, even if some things are rough around the edges.
> >
> > I have had a LOT of overtime at my $dayjob lately, which has kept me
> > from working much on NuttX. However, I don't want to let the workflow
> > fall by the wayside. I would like to get it wrapped up so we can vote
> > on it soon.
> >
> > Please, could we have some willing volunteers proofread the document,
> > fix some of the "REVISIT" parts, and help push this document that last
> > little bit to get it into a "shippable" state?
> >
> > [1]
> >
> >
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
> > )
> >
> > Thanks,
> > Nathan
> >
>

unconditional 32kHz xtal oscillator on SAM34

[Bernd Walter]

I have had problens with a new SAM4S based board in that it hang eraly
during startup, before initializing my 12MHz xtal.
Also the SWD didn't work anymore until I erased the chip.
Since the SWD didn't work it was quite obvious that there is some clock
related issue.
I've found out that the startup code unconditionally switches to an
external 32kHz xtal.
On my board I didn't need one.
Interestingly I had no such problem on a SAM4E board, but there is
a small difference between those boards in that the SAM4E has XIN32/XOU3
pins unconnected and the SAM4S has XIN32 used as GPIO.
Or maybe the SAM4E just behave differently when trying to init an unhooked
32kHz xtal.
However, after commenting the sam_supcsetup() call my board worked fine.
I think there should be an option to initialize the 32kHz xtal or not.

arch/arm/src/sam34/sam_clockconfig.c:

/
 * Name: sam_supcsetup
 *
 * Description:
 *   Select the external slow clock
 *
 /

static inline void sam_supcsetup(void)
{
  /* Check if the 32-kHz is already selected */

  if ((getreg32(SAM_SUPC_SR) & SUPC_SR_OSCSEL) == 0)
{
  uint32_t delay;

  putreg32((SUPC_CR_XTALSEL | SUPR_CR_KEY), SAM_SUPC_CR);
  for (delay = 0;
   (getreg32(SAM_SUPC_SR) & SUPC_SR_OSCSEL) == 0 && delay < UINT32_MAX;
   delay++);
}
}

...

/
 * Name: sam_clockconfig
 * 
 * Description:
 *   Called to initialize the SAM3/4.  This does whatever setup is needed to 
put the
 *   SoC in a usable state.  This includes the initialization of clocking using 
the
 *   settings in board.h.  (After power-on reset, the SAM3/4 is initially 
running on
 *   a 4MHz internal RC clock).  This function also performs other low-level 
chip
 *   initialization of the chip including EFC, master clock, IRQ & watchdog
 *   configuration.
 *
 
/

void sam_clockconfig(void)
{
  /* Configure embedded flash access */

  sam_efcsetup();
  
  /* Configure the watchdog timer */
  
  sam_wdtsetup();
 
  /* Setup the supply controller to use the external slow clock */

  sam_supcsetup();
  
  /* Initialize clocking */
 
  sam_pmcsetup();
 
  /* Optimize CPU setting for speed */

  sam_enabledefaultmaster();
}

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Alan Carvalho de Assis]

Hi Bernd,

On 1/28/20, Bernd Walter  wrote:
> I have had problens with a new SAM4S based board in that it hang eraly
> during startup, before initializing my 12MHz xtal.
> Also the SWD didn't work anymore until I erased the chip.
> Since the SWD didn't work it was quite obvious that there is some clock
> related issue.
> I've found out that the startup code unconditionally switches to an
> external 32kHz xtal.
> On my board I didn't need one.
> Interestingly I had no such problem on a SAM4E board, but there is
> a small difference between those boards in that the SAM4E has XIN32/XOU3
> pins unconnected and the SAM4S has XIN32 used as GPIO.
> Or maybe the SAM4E just behave differently when trying to init an unhooked
> 32kHz xtal.
> However, after commenting the sam_supcsetup() call my board worked fine.
> I think there should be an option to initialize the 32kHz xtal or not.
>

Please check how other boards are doing it. Normally you have a DEFINE
USE_CLOCK_XYZ inside the boardname/include/board.h.

I faced an issue similar to your on SAMD21, it was defined to use
external crystal, but my board didn't have one. When I enabled the
internal clock the serial console wasn't working correctly. Then
Alexander noticed that it was missing a function to read the NVRAM
calibration data to use with the internal RC clock.

BR,

Alan

Generic SPI interface to LCD

[Dave Marples]

Greg,

Here's a patch^h^h^h^h^htxt which allows the use of a generic spi 
interface for controlling an LCD display.  It has been tested with the 
ili9341 but should work with others without too much pain...hopefully 
this will be useful to Ben, who I know has been looking for such a thing.


To use it;

1) include nuttx/lcd/lcddrv_spiif.h

2) Create an spi device;

struct spi_dev_s *g_bound_spi  = imxrt_spi_register(2);

3) Instantiate the interface;

struct lcddrv_lcd_s *dev = lcddrv_spiif_initialize( g_bound_spi );

4) Bind the interface to the lcd;

g_lcd = ili9341_initialize((struct ili9341_lcd_s *)dev, 
CONFIG_IMXRT_VB_ILI9341_LCDDEVICE);


You should then be able to use the lcd as normal. Comments and brickbats 
welcome.


Regards

DAVE


diff --git a/arch/arm/src/imxrt/imxrt_lpspi.c b/arch/arm/src/imxrt/imxrt_lpspi.c
index b33cee894f..8c8838662a 100644
--- a/arch/arm/src/imxrt/imxrt_lpspi.c
+++ b/arch/arm/src/imxrt/imxrt_lpspi.c
@@ -1,4 +1,4 @@
-/
+/*
  * arm/arm/src/imxrt/imxrt_lpspi.c
  *
  *   Copyright (C) 2018 Gregory Nutt. All rights reserved.
@@ -32,34 +32,35 @@
  * ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
  * POSSIBILITY OF SUCH DAMAGE.
  *
- 
/
+ */
 
-/
- * The external functions, imxrt_lpspi1/2/3/4select and 
imxrt_lpspi1/2/3/4status
- * must be provided by board-specific logic.  They are implementations of the 
select
- * and status methods of the SPI interface defined by struct imxrt_lpspi_ops_s 
(see
- * include/nuttx/spi/spi.h). All other methods (including 
imxrt_lpspibus_initialize())
- * are provided by common IMXRT logic.  To use this common SPI logic on your
- * board:
+/*
+ * The external functions, imxrt_lpspi1/2/3/4select and
+ * imxrt_lpspi1/2/3/4status must be provided by board-specific logic.
+ * They are implementations of the select and status methods of the SPI
+ * interface defined by struct imxrt_lpspi_ops_s (see
+ * include/nuttx/spi/spi.h). All other methods (including
+ * imxrt_lpspibus_initialize()) are provided by common IMXRT logic.
+ * To use this common SPI logic on your board:
  *
  *   1. Provide logic in imxrt_boardinitialize() to configure SPI chip select
  *  pins.
  *   2. Provide imxrt_lpspi1/2/3/4select() and imxrt_lpspi1/2/3/4status()
- *  functions in your board-specific logic.  These functions will perform 
chip
- *  selection and status operations using GPIOs in the way your board is
- *  configured.
- *   3. Add a calls to imxrt_lpspibus_initialize() in your low level 
application
- *  initialization logic
- *   4. The handle returned by imxrt_lpspibus_initialize() may then be used to 
bind the
- *  SPI driver to higher level logic (e.g., calling
+ *  functions in your board-specific logic.  These functions will perform
+ *  chip selection and status operations using GPIOs in the way your board
+ *  is configured.
+ *   3. Add a calls to imxrt_lpspibus_initialize() in your low level
+ *  application initialization logic
+ *   4. The handle returned by imxrt_lpspibus_initialize() may then be used to
+ *  bind the SPI driver to higher level logic (e.g., calling
  *  mmcsd_lpspislotinitialize(), for example, will bind the SPI driver to
  *  the SPI MMC/SD driver).
  *
- 
/
+ */
 
-/
+/*
  * Included Files
- 
/
+ */
 
 #include 
 
@@ -94,11 +95,11 @@
 #if defined(CONFIG_IMXRT_LPSPI1) || defined(CONFIG_IMXRT_LPSPI2) || \
 defined(CONFIG_IMXRT_LPSPI3) || defined(CONFIG_IMXRT_LPSPI4)
 
-/
+/*
  * Pre-processor Definitions
- 
/
+ /
 
-/* Configuration 
/
+/* Configuration /
 
 /* SPI interrupts 

Porting USB Host driver on to RX65N controller...

[Phani Kumar]

Hi Greg and all,
As part of porting USB Host driver for RX65N, I am referring to LPC17_40
USB Host port. Here are some of the points, where I need your suggestions.
Please let me know if you have any pointers/ other references on this.
HCCA (Host communication area details), TDTAIL (Transfer descriptor
details) and EDCTRL (Endpoint descriptor details) are referred as
respective structures. LPC17_40 has these structures located at some RAM
Area (I think, LPC17xx has dedicated memory for USB Host or something like
that) and uses this memory area for these structures (where start address
is fixed at starting point of memory, and with each size, the next
structure is referred).
In RX65N, would it be OK, to use normal memory and allocate these
structures statically - in the beginning of the file itself? Or do you
suggest to allocate memory in the init function *__usbhost_initialize ()
function and use them?
With best regards,
Phani.

>

Re: [DISCUSS] Wrapping up the Workflow document

[Miguel Ángel Herranz]

Hi Nathan,

I reviewed the document and added some inlines comments (not sure if they
are not recommended for use though).

I haven't edited/added any text though, but I will be glad to help if
needed.

Cheers,
Miguel

On Fri, Jan 24, 2020 at 4:29 PM Nathan Hartman 
wrote:

> Hi all,
>
> The proposed Workflow document (see [1]) has a substantial amount of
> good information in it.
>
> It is not yet 100% percent complete:
> (1) There are several "REVISIT" notes throughout.
> (2) A few sections toward the end aren't written yet.
>
> However, by the 80-20 rule, I think the most important parts have been
> written, even if some things are rough around the edges.
>
> I have had a LOT of overtime at my $dayjob lately, which has kept me
> from working much on NuttX. However, I don't want to let the workflow
> fall by the wayside. I would like to get it wrapped up so we can vote
> on it soon.
>
> Please, could we have some willing volunteers proofread the document,
> fix some of the "REVISIT" parts, and help push this document that last
> little bit to get it into a "shippable" state?
>
> [1]
>
> https://cwiki.apache.org/confluence/display/NUTTX/Code+Contribution+Workflow+--+Brennan+Ashton
> )
>
> Thanks,
> Nathan
>

[GitHub] [incubator-nuttx-testing] maht opened a new pull request #2: Multibranch pipeline job example

[GitBox]

maht opened a new pull request #2: Multibranch pipeline job example
URL: https://github.com/apache/incubator-nuttx-testing/pull/2
 
 
   This is an example of code to help to setup a multibranch pipeline job as 
described in this [continuous integration draft 
proposal](https://cwiki.apache.org/confluence/display/NUTTX/Continuous+integration+--+Miguel+Herranz),
 to help discussion on the topic.
   
   This pull request is not intended to be functional or merged as it is, 
unless used as scaffolding to integrated real NuttX scripts for build and test.
   
   It consists in a pipeline script defined as a external library in the 
testing repo that can be used by another job in the main one.
   
   The expected output should be similar to what can be seen in the following 
link: http://nuttx.ci.midocloud.net:8080/blue/pipelines


This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
 
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org


With regards,
Apache Git Services

Re: Jenkins CI

[Miguel Ángel Herranz]

Hi,

after some research about new releases of Jenkins, it seems that my
proposal can be improved towards a simpler setup, so I modified it.

I have included some code as pull requests that could be useful to discuss
upon: https://github.com/apache/incubator-nuttx-testing/pull/2 and
https://github.com/apache/incubator-nuttx/pull/174

The actual logic from Haitao scripts can be used inside the pipeline
definition, so we could have a mostly functional "Github pull request based
workflow", once a comitter with enough rights could create the jobs in
builds.apache.org (I am still waiting confirmation for the CCLA, sorry, and
anyway the access is not granted).

Cheers,
Miguel




On Tue, Jan 21, 2020 at 1:11 PM Miguel Ángel Herranz 
wrote:

>
> > We probably can get infra to add you, submitting an ICLA might help as
> that could be used to create an account.
>
> Thanks, good to know. I am asking my employer about including me in a
> corporate one (CCLA [1]), but if it is too much paperwork I guess I can
> just submit the ICLA. Let's see.
>
> [1] https://www.apache.org/licenses/contributor-agreements.html
>
> On Tue, Jan 21, 2020 at 2:01 AM Justin Mclean 
> wrote:
>
>> Hi,
>>
>> > Oh, I did check that wiki page but I was not aware that it was a
>> > requirement to be a comitter or PPMC member to have an LDAP account,
>> but it
>> > makes sense, thanks anyway.
>>
>> We probably can get infra to add you, submitting an ICLA might help as
>> that could be used to create an account.
>>
>> Thanks,
>> Justin
>>
>>
>>

Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Bernd Walter]

On Tue, Jan 28, 2020 at 12:40:12PM -0300, Alan Carvalho de Assis wrote:
> Hi Bernd,
> 
> On 1/28/20, Bernd Walter  wrote:
> > I have had problens with a new SAM4S based board in that it hang eraly
> > during startup, before initializing my 12MHz xtal.
> > Also the SWD didn't work anymore until I erased the chip.
> > Since the SWD didn't work it was quite obvious that there is some clock
> > related issue.
> > I've found out that the startup code unconditionally switches to an
> > external 32kHz xtal.
> > On my board I didn't need one.
> > Interestingly I had no such problem on a SAM4E board, but there is
> > a small difference between those boards in that the SAM4E has XIN32/XOU3
> > pins unconnected and the SAM4S has XIN32 used as GPIO.
> > Or maybe the SAM4E just behave differently when trying to init an unhooked
> > 32kHz xtal.
> > However, after commenting the sam_supcsetup() call my board worked fine.
> > I think there should be an option to initialize the 32kHz xtal or not.
> >
> 
> Please check how other boards are doing it. Normally you have a DEFINE
> USE_CLOCK_XYZ inside the boardname/include/board.h.

Ok - will do that.

> I faced an issue similar to your on SAMD21, it was defined to use
> external crystal, but my board didn't have one. When I enabled the
> internal clock the serial console wasn't working correctly. Then
> Alexander noticed that it was missing a function to read the NVRAM
> calibration data to use with the internal RC clock.

I have had the same problem with wrong uart clock on a few identic SAMD21
boards, but results were different.
My board had been running on internal RC without USB.
An external 12MHz xtal existed, but I hadn't used it because of lazyness.
My problem however wasn't the RC, because after switching to the xtal
the problem still existed.
In my case it was the DFLL and everything was fine after switching to
the DPLL.
The DPLL however is not an option if you want to use the RC and
still being able to run device USB.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: [nuttx] unconditional 32kHz xtal oscillator on SAM34

[Bernd Walter]

On Tue, Jan 28, 2020 at 05:22:08PM +0100, Bernd Walter wrote:
> On Tue, Jan 28, 2020 at 12:40:12PM -0300, Alan Carvalho de Assis wrote:
> > Hi Bernd,
> > 
> > On 1/28/20, Bernd Walter  wrote:
> > > I have had problens with a new SAM4S based board in that it hang eraly
> > > during startup, before initializing my 12MHz xtal.
> > > Also the SWD didn't work anymore until I erased the chip.
> > > Since the SWD didn't work it was quite obvious that there is some clock
> > > related issue.
> > > I've found out that the startup code unconditionally switches to an
> > > external 32kHz xtal.
> > > On my board I didn't need one.
> > > Interestingly I had no such problem on a SAM4E board, but there is
> > > a small difference between those boards in that the SAM4E has XIN32/XOU3
> > > pins unconnected and the SAM4S has XIN32 used as GPIO.
> > > Or maybe the SAM4E just behave differently when trying to init an unhooked
> > > 32kHz xtal.
> > > However, after commenting the sam_supcsetup() call my board worked fine.
> > > I think there should be an option to initialize the 32kHz xtal or not.
> > >
> > 
> > Please check how other boards are doing it. Normally you have a DEFINE
> > USE_CLOCK_XYZ inside the boardname/include/board.h.
> 
> Ok - will do that.
> 
> > I faced an issue similar to your on SAMD21, it was defined to use
> > external crystal, but my board didn't have one. When I enabled the
> > internal clock the serial console wasn't working correctly. Then
> > Alexander noticed that it was missing a function to read the NVRAM
> > calibration data to use with the internal RC clock.
> 
> I have had the same problem with wrong uart clock on a few identic SAMD21
> boards, but results were different.
> My board had been running on internal RC without USB.
> An external 12MHz xtal existed, but I hadn't used it because of lazyness.
> My problem however wasn't the RC, because after switching to the xtal
> the problem still existed.
> In my case it was the DFLL and everything was fine after switching to
> the DPLL.
> The DPLL however is not an option if you want to use the RC and
> still being able to run device USB.

Oh - by the way.
When you use an extarnal xtal on a SAMD21 disable the oscillator power saving
feature (BOARD_DPLL_LPEN/SYSCTRL_DPLLCTRLB_LPEN) while debugging.
The amplitude is insanely low and I couldn't see it swinging on my scope.

-- 
B.Walter  http://www.bwct.de
Modbus/TCP Ethernet I/O Baugruppen, ARM basierte FreeBSD Rechner uvm.

Re: [DISCUSS] Wrapping up the Workflow document

[Gregory Nutt]

I reviewed the document and added some inlines comments (not sure if they
are not recommended for use though).

I haven't edited/added any text though, but I will be glad to help if
needed.

We need to get you on the PPMC where it would be easier for you to make
contributions 

Re: [DISCUSS] Wrapping up the Workflow document

[Nathan Hartman]

On Tue, Jan 28, 2020 at 11:49 AM Miguel Ángel Herranz
 wrote:

> Hi Nathan,
>
> I reviewed the document and added some inlines comments (not sure if they
> are not recommended for use though).
>
> I haven't edited/added any text though, but I will be glad to help if
> needed.


Hello Miguel,

Thank you for your message. I replied to a couple of your inline comments.
(I had no idea there was such a feature!)

Please, feel free to improve the text. (Let us know if you need someone to
set up Confluence editing access for you.)

Thank you very much,
Nathan

Re: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif,

Yes I know. It is a defensive move, on my part, that makes it safe when
working with multiple companies who might not appreciate me sharing their
IP.

David

On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche <
abdelatif.guettou...@gmail.com> wrote:

> Hi David,
>
> You can merge local branch from a different remote than the branch is
> tracking, giving that the merge is possible of course.
>
> On Wed, Jan 29, 2020 at 12:15 AM David Sidrane 
> wrote:
> >
> > Hi Abdelatif
> >
> > > Why do you prefer git reset --hard /master to git merge
> > /master after a fetch?
> >
> > Because with multiple remotes I am sure what local master is set to with
> a
> > hard reset.
> > There is no possibility of merging remote A into remote B master locally
> and
> > no merge if I had the wrong remote.
> >
> > David
> >
> > -Original Message-
> > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > Sent: Tuesday, January 28, 2020 5:04 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> >
> > Hi David,
> >
> > In the workflow, deleting the branch is only suggested _after_ the PR
> > has been merged.
> > What you are describing is during review, which is missing from the
> > workflow.
> >
> > > I had seen a lot of PR that came into bitbucket in the past with many
> > > merge
> > > commits from upstream. Rebasing avoids that.
> > Yep, still some in Github as well. I personally cherry pick relevant
> > commits from those PRs during review.
> >
> > > Should be fetch and or pull and should only result in a fast forward -
> > > with
> > > many remotes I use git reset --hard  /master after a fetch.
> > > Then as you say, I  rebase my wip on it.
> >
> > With all the work in a separate branch, local fork/master shall always
> > be behind upstream/master, which will result in a fast forward.
> >
> > Why do you prefer git reset --hard /master to git merge
> > /master after a fetch?
> >
> >
> >
> >
> > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 
> > wrote:
> > >
> > > Hi Abdelatif,
> > >
> > > > Are you assuming that the work is always on a same feature that you
> > > > submit
> > > PRs gradually?
> > >
> > > It can be but does not have to be.
> > >
> > > > What are the cons of deleting branches?
> > >
> > > Lost work. A botched commit by committer and you have nothing to
> compare
> > > it
> > > to. branches are FREE.
> > >
> > > > What merge commits?
> > >
> > > I had seen a lot of PR that came into bitbucket in the past with many
> > > merge
> > > commits from upstream. Rebasing avoids that.
> > >
> > > (fetch + merge from upstream)
> > > Should be fetch and or pull and should only result in a fast forward -
> > > with
> > > many remotes I use git reset --hard  /master after a fetch.
> > > Then as you say, I  rebase my wip on it.
> > >
> > > -Original Message-
> > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > > Sent: Tuesday, January 28, 2020 2:17 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> > >
> > > Hi David,
> > >
> > > Are you assuming that the work is always on a same feature that you
> submit
> > > PRs gradually?
> > >
> > > The git usage looks off to me. It would be better to avoid deleting
> > > branches
> > > > and using noises merge commits.
> > > >
> > > What are the cons of deleting branches?
> > > What merge commits? I don't understand this last part, do you mean that
> > > the
> > > procedure described in the workflow will generate merge commits?
> > > Keeping a WIP branch in synch is missing from the workflow.
> > > Basically same as you described, that should consist of synching master
> > > (fetch + merge from upstream) then rebasing the branch on top of
> master.
> > >
> > >
> > > On Tue, Jan 28, 2020 at 8:52 PM David Sidrane  >
> > > wrote:
> > >
> > > > The git usage looks off to me. It would be better to avoid deleting
> > > > branches
> > > > and using noises merge commits.
> > > >
> > > >
> > > > Assume the "upstream" remote is ASF repo
> > > > Assume "prj" remote is my remote
> > > > Assume your code is not in master on your fork.
> > > >
> > > > Submission:
> > > >
> > > > git push prj  master_my_branch
> > > >
> > > > open a PR on git hub (Fill out the template - we need one)
> > > > ...
> > > >
> > > > Your PR comes into master: - this can be as is:no committer
> > > > modification
> > > > or
> > > > with modification by the committer.
> > > >
> > > > Reintegration
> > > > Put your current work on top of latest master (with your
> contribution +
> > > > others)
> > > >
> > > > git checkout master
> > > > git fetch upstream
> > > > git pull upstream master (it should only be a fast forward not merge
> > > > commits) OR git reset --hard upstream/master (no question what you
> get)
> > > > git checkout master_my_branch
> > > > (optionally if PR codes was modified by committer  - to keep your
> work
> > > > safe - git -b checkout 

RE: [DISCUSS] Wrapping up the Workflow document

[David Sidrane]

Hi Abdelatif

> Why do you prefer git reset --hard /master to git merge
/master after a fetch?

Because with multiple remotes I am sure what local master is set to with a
hard reset.
There is no possibility of merging remote A into remote B master locally and
no merge if I had the wrong remote.

David

-Original Message-
From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
Sent: Tuesday, January 28, 2020 5:04 PM
To: dev@nuttx.apache.org
Subject: Re: [DISCUSS] Wrapping up the Workflow document

Hi David,

In the workflow, deleting the branch is only suggested _after_ the PR
has been merged.
What you are describing is during review, which is missing from the
workflow.

> I had seen a lot of PR that came into bitbucket in the past with many
> merge
> commits from upstream. Rebasing avoids that.
Yep, still some in Github as well. I personally cherry pick relevant
commits from those PRs during review.

> Should be fetch and or pull and should only result in a fast forward -
> with
> many remotes I use git reset --hard  /master after a fetch.
> Then as you say, I  rebase my wip on it.

With all the work in a separate branch, local fork/master shall always
be behind upstream/master, which will result in a fast forward.

Why do you prefer git reset --hard /master to git merge
/master after a fetch?




On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 
wrote:
>
> Hi Abdelatif,
>
> > Are you assuming that the work is always on a same feature that you
> > submit
> PRs gradually?
>
> It can be but does not have to be.
>
> > What are the cons of deleting branches?
>
> Lost work. A botched commit by committer and you have nothing to compare
> it
> to. branches are FREE.
>
> > What merge commits?
>
> I had seen a lot of PR that came into bitbucket in the past with many
> merge
> commits from upstream. Rebasing avoids that.
>
> (fetch + merge from upstream)
> Should be fetch and or pull and should only result in a fast forward -
> with
> many remotes I use git reset --hard  /master after a fetch.
> Then as you say, I  rebase my wip on it.
>
> -Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Tuesday, January 28, 2020 2:17 PM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi David,
>
> Are you assuming that the work is always on a same feature that you submit
> PRs gradually?
>
> The git usage looks off to me. It would be better to avoid deleting
> branches
> > and using noises merge commits.
> >
> What are the cons of deleting branches?
> What merge commits? I don't understand this last part, do you mean that
> the
> procedure described in the workflow will generate merge commits?
> Keeping a WIP branch in synch is missing from the workflow.
> Basically same as you described, that should consist of synching master
> (fetch + merge from upstream) then rebasing the branch on top of master.
>
>
> On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
> wrote:
>
> > The git usage looks off to me. It would be better to avoid deleting
> > branches
> > and using noises merge commits.
> >
> >
> > Assume the "upstream" remote is ASF repo
> > Assume "prj" remote is my remote
> > Assume your code is not in master on your fork.
> >
> > Submission:
> >
> > git push prj  master_my_branch
> >
> > open a PR on git hub (Fill out the template - we need one)
> > ...
> >
> > Your PR comes into master: - this can be as is:no committer
> > modification
> > or
> > with modification by the committer.
> >
> > Reintegration
> > Put your current work on top of latest master (with your contribution +
> > others)
> >
> > git checkout master
> > git fetch upstream
> > git pull upstream master (it should only be a fast forward not merge
> > commits) OR git reset --hard upstream/master (no question what you get)
> > git checkout master_my_branch
> > (optionally if PR codes was modified by committer  - to keep your work
> > safe - git -b checkout master_my_branch_PR && git checkout
> > master_my_branch)
> > (optionally if PR codes was modified by committer  git reset --hard
> >  > is
> > the parent of master_my_branch started>)
> > git rebase master
> >
> > In reality if the PR was taken as is (no committer  modification) the
> > rebase
> > on master will only add others changes under your WIP.
> >
> >
> > Alternate for backporting  - Cherry pick your work back to your fork.
> >
> > This workflow ensures your branch is equal in format to the upstream and
> > no
> > others changes. - This may be more stable.
> > git checkout master
> > git fetch upstream
> > git pull upstream master OR git reset --hard upstream/master (no
> > question
> > what you get)
> >
> > git checkout master_my_branch
> > git  -b checkout master_my_branch_PR && git checkout master_my_branch
> > git reset --hard 
> > git log master --oneline
> > ^C
> > git cherry-pick  ..
> >
> > add -e to change the commit message i.e add [BACKPORT]
> >
> > David
> >
> > -Original 

Re: [DISCUSS] Wrapping up the Workflow document

[Abdelatif Guettouche]

Hi David,

You can merge local branch from a different remote than the branch is
tracking, giving that the merge is possible of course.

On Wed, Jan 29, 2020 at 12:15 AM David Sidrane  wrote:
>
> Hi Abdelatif
>
> > Why do you prefer git reset --hard /master to git merge
> /master after a fetch?
>
> Because with multiple remotes I am sure what local master is set to with a
> hard reset.
> There is no possibility of merging remote A into remote B master locally and
> no merge if I had the wrong remote.
>
> David
>
> -Original Message-
> From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> Sent: Tuesday, January 28, 2020 5:04 PM
> To: dev@nuttx.apache.org
> Subject: Re: [DISCUSS] Wrapping up the Workflow document
>
> Hi David,
>
> In the workflow, deleting the branch is only suggested _after_ the PR
> has been merged.
> What you are describing is during review, which is missing from the
> workflow.
>
> > I had seen a lot of PR that came into bitbucket in the past with many
> > merge
> > commits from upstream. Rebasing avoids that.
> Yep, still some in Github as well. I personally cherry pick relevant
> commits from those PRs during review.
>
> > Should be fetch and or pull and should only result in a fast forward -
> > with
> > many remotes I use git reset --hard  /master after a fetch.
> > Then as you say, I  rebase my wip on it.
>
> With all the work in a separate branch, local fork/master shall always
> be behind upstream/master, which will result in a fast forward.
>
> Why do you prefer git reset --hard /master to git merge
> /master after a fetch?
>
>
>
>
> On Tue, Jan 28, 2020 at 11:16 PM David Sidrane 
> wrote:
> >
> > Hi Abdelatif,
> >
> > > Are you assuming that the work is always on a same feature that you
> > > submit
> > PRs gradually?
> >
> > It can be but does not have to be.
> >
> > > What are the cons of deleting branches?
> >
> > Lost work. A botched commit by committer and you have nothing to compare
> > it
> > to. branches are FREE.
> >
> > > What merge commits?
> >
> > I had seen a lot of PR that came into bitbucket in the past with many
> > merge
> > commits from upstream. Rebasing avoids that.
> >
> > (fetch + merge from upstream)
> > Should be fetch and or pull and should only result in a fast forward -
> > with
> > many remotes I use git reset --hard  /master after a fetch.
> > Then as you say, I  rebase my wip on it.
> >
> > -Original Message-
> > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > Sent: Tuesday, January 28, 2020 2:17 PM
> > To: dev@nuttx.apache.org
> > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> >
> > Hi David,
> >
> > Are you assuming that the work is always on a same feature that you submit
> > PRs gradually?
> >
> > The git usage looks off to me. It would be better to avoid deleting
> > branches
> > > and using noises merge commits.
> > >
> > What are the cons of deleting branches?
> > What merge commits? I don't understand this last part, do you mean that
> > the
> > procedure described in the workflow will generate merge commits?
> > Keeping a WIP branch in synch is missing from the workflow.
> > Basically same as you described, that should consist of synching master
> > (fetch + merge from upstream) then rebasing the branch on top of master.
> >
> >
> > On Tue, Jan 28, 2020 at 8:52 PM David Sidrane 
> > wrote:
> >
> > > The git usage looks off to me. It would be better to avoid deleting
> > > branches
> > > and using noises merge commits.
> > >
> > >
> > > Assume the "upstream" remote is ASF repo
> > > Assume "prj" remote is my remote
> > > Assume your code is not in master on your fork.
> > >
> > > Submission:
> > >
> > > git push prj  master_my_branch
> > >
> > > open a PR on git hub (Fill out the template - we need one)
> > > ...
> > >
> > > Your PR comes into master: - this can be as is:no committer
> > > modification
> > > or
> > > with modification by the committer.
> > >
> > > Reintegration
> > > Put your current work on top of latest master (with your contribution +
> > > others)
> > >
> > > git checkout master
> > > git fetch upstream
> > > git pull upstream master (it should only be a fast forward not merge
> > > commits) OR git reset --hard upstream/master (no question what you get)
> > > git checkout master_my_branch
> > > (optionally if PR codes was modified by committer  - to keep your work
> > > safe - git -b checkout master_my_branch_PR && git checkout
> > > master_my_branch)
> > > (optionally if PR codes was modified by committer  git reset --hard
> > >  > > is
> > > the parent of master_my_branch started>)
> > > git rebase master
> > >
> > > In reality if the PR was taken as is (no committer  modification) the
> > > rebase
> > > on master will only add others changes under your WIP.
> > >
> > >
> > > Alternate for backporting  - Cherry pick your work back to your fork.
> > >
> > > This workflow ensures your branch is equal in format to the upstream and
> > > no
> > > others 

Re: [DISCUSS] Wrapping up the Workflow document

[Abdelatif Guettouche]

Hi David,

Sorry for pointing the obvious. :)

I do a lot of defensive moves myself too.
I never use fetch, pull, mege or push without paramters.
I also give my local branches different names than the remotes they are
tracking. (Usally just a prefix of the remote)
Pushing will then require specifying source and destination (git push
 src:dest)
That's more typing, but prevents some mistakes.

On Wed, Jan 29, 2020, 01:38 David Sidrane  wrote:

> Hi Abdelatif,
>
> Yes I know. It is a defensive move, on my part, that makes it safe when
> working with multiple companies who might not appreciate me sharing their
> IP.
>
> David
>
> On Tue, Jan 28, 2020, 4:30 PM Abdelatif Guettouche <
> abdelatif.guettou...@gmail.com> wrote:
>
> > Hi David,
> >
> > You can merge local branch from a different remote than the branch is
> > tracking, giving that the merge is possible of course.
> >
> > On Wed, Jan 29, 2020 at 12:15 AM David Sidrane 
> > wrote:
> > >
> > > Hi Abdelatif
> > >
> > > > Why do you prefer git reset --hard /master to git merge
> > > /master after a fetch?
> > >
> > > Because with multiple remotes I am sure what local master is set to
> with
> > a
> > > hard reset.
> > > There is no possibility of merging remote A into remote B master
> locally
> > and
> > > no merge if I had the wrong remote.
> > >
> > > David
> > >
> > > -Original Message-
> > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > > Sent: Tuesday, January 28, 2020 5:04 PM
> > > To: dev@nuttx.apache.org
> > > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> > >
> > > Hi David,
> > >
> > > In the workflow, deleting the branch is only suggested _after_ the PR
> > > has been merged.
> > > What you are describing is during review, which is missing from the
> > > workflow.
> > >
> > > > I had seen a lot of PR that came into bitbucket in the past with many
> > > > merge
> > > > commits from upstream. Rebasing avoids that.
> > > Yep, still some in Github as well. I personally cherry pick relevant
> > > commits from those PRs during review.
> > >
> > > > Should be fetch and or pull and should only result in a fast forward
> -
> > > > with
> > > > many remotes I use git reset --hard  /master after a fetch.
> > > > Then as you say, I  rebase my wip on it.
> > >
> > > With all the work in a separate branch, local fork/master shall always
> > > be behind upstream/master, which will result in a fast forward.
> > >
> > > Why do you prefer git reset --hard /master to git merge
> > > /master after a fetch?
> > >
> > >
> > >
> > >
> > > On Tue, Jan 28, 2020 at 11:16 PM David Sidrane <
> david.sidr...@nscdg.com>
> > > wrote:
> > > >
> > > > Hi Abdelatif,
> > > >
> > > > > Are you assuming that the work is always on a same feature that you
> > > > > submit
> > > > PRs gradually?
> > > >
> > > > It can be but does not have to be.
> > > >
> > > > > What are the cons of deleting branches?
> > > >
> > > > Lost work. A botched commit by committer and you have nothing to
> > compare
> > > > it
> > > > to. branches are FREE.
> > > >
> > > > > What merge commits?
> > > >
> > > > I had seen a lot of PR that came into bitbucket in the past with many
> > > > merge
> > > > commits from upstream. Rebasing avoids that.
> > > >
> > > > (fetch + merge from upstream)
> > > > Should be fetch and or pull and should only result in a fast forward
> -
> > > > with
> > > > many remotes I use git reset --hard  /master after a fetch.
> > > > Then as you say, I  rebase my wip on it.
> > > >
> > > > -Original Message-
> > > > From: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com]
> > > > Sent: Tuesday, January 28, 2020 2:17 PM
> > > > To: dev@nuttx.apache.org
> > > > Subject: Re: [DISCUSS] Wrapping up the Workflow document
> > > >
> > > > Hi David,
> > > >
> > > > Are you assuming that the work is always on a same feature that you
> > submit
> > > > PRs gradually?
> > > >
> > > > The git usage looks off to me. It would be better to avoid deleting
> > > > branches
> > > > > and using noises merge commits.
> > > > >
> > > > What are the cons of deleting branches?
> > > > What merge commits? I don't understand this last part, do you mean
> that
> > > > the
> > > > procedure described in the workflow will generate merge commits?
> > > > Keeping a WIP branch in synch is missing from the workflow.
> > > > Basically same as you described, that should consist of synching
> master
> > > > (fetch + merge from upstream) then rebasing the branch on top of
> > master.
> > > >
> > > >
> > > > On Tue, Jan 28, 2020 at 8:52 PM David Sidrane <
> david.sidr...@nscdg.com
> > >
> > > > wrote:
> > > >
> > > > > The git usage looks off to me. It would be better to avoid deleting
> > > > > branches
> > > > > and using noises merge commits.
> > > > >
> > > > >
> > > > > Assume the "upstream" remote is ASF repo
> > > > > Assume "prj" remote is my remote
> > > > > Assume your code is not in master on your fork.
> > > > >
> > > > > Submission:
> > > > >
> 

NuttX2020: Call for Participation

[Alan Carvalho de Assis]

Hi Everybody,

The NuttX International Workshop is open!

Please submit your proposal:

https://nuttx.events/call-for-participation/

Passive participation is also accepted, just select the class: Passive
Participant.

BR,

Alan

NuttX at FOSDEM 2020

[Brennan Ashton]

Being the large opensource conference that it is, I was curious if anyone
in this project or Apache was planning on attending. I'm giving an
unrelated talk, but it would be great to meet some more of you in person.


--Brennan

Re: Jenkins CI

[Justin Mclean]

Hi,

> Thanks, good to know. I am asking my employer about including me in a
> corporate one (CCLA [1]), but if it is too much paperwork I guess I can
> just submit the ICLA. 

You would need to submit an ICLA. The CCLA is for more for your employer 
benefit not ours.

Thanks,
Justin

Re: NuttX at FOSDEM 2020

[Alan Carvalho de Assis]

Hi Brenan,

Did you see it: https://fosdem.org/2020/schedule/event/iotnuttx/

BR,

Alan

On 1/28/20, Brennan Ashton  wrote:
> Being the large opensource conference that it is, I was curious if anyone
> in this project or Apache was planning on attending. I'm giving an
> unrelated talk, but it would be great to meet some more of you in person.
>
>
> --Brennan
>

Re: NuttX at FOSDEM 2020

[Justin Mclean]

Hi,

> Being the large opensource conference that it is, I was curious if anyone
> in this project or Apache was planning on attending.

There's lots of Apache people going, pop by their booth and say hi. I will not 
be there.

Thanks,
Justin