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

[Apache Jenkins Server]

See 

Changes:


--
[...truncated 304.48 KB...]

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/minibasic

Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
--2020-07-04 05:32:54--  
https://github.com/ARMmbed/littlefs/archive/v2.2.1.tar.gz
Resolving github.com (github.com)... 192.30.255.113
Connecting to github.com (github.com)|192.30.255.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1 [following]
--2020-07-04 05:32:54--  
https://codeload.github.com/ARMmbed/littlefs/tar.gz/v2.2.1
Resolving codeload.github.com (codeload.github.com)... 192.30.255.120
Connecting to codeload.github.com (codeload.github.com)|192.30.255.120|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/x-gzip]
Saving to: 'littlefs/v2.2.1.tar.gz'

v2.2.1.tar.gz   [<=> ]   0  --.-KB/s   
v2.2.1.tar.gz   [ <=>] 111.57K  --.-KB/sin 0.01s   

2020-07-04 05:32:54 (7.27 MB/s) - 'littlefs/v2.2.1.tar.gz' saved [114250]

  Normalize sim/tcpblaster

Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/touchscreen

Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/bas

Configuration/Tool: sim/mtdpart

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/mtdpart

Configuration/Tool: sim/spiffs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/spiffs

Configuration/Tool: sim/ustream

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/ustream

Configuration/Tool: sim/userfs

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...
  Normalize sim/userfs

Configuration/Tool: sim/rpproxy

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
--2020-07-04 05:36:13--  
https://github.com/OpenAMP/libmetal/archive/v2020.04.0.zip
Resolving github.com (github.com)... 192.30.255.112
Connecting to github.com (github.com)|192.30.255.112|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0 
[following]
--2020-07-04 05:36:14--  
https://codeload.github.com/OpenAMP/libmetal/zip/v2020.04.0
Resolving codeload.github.com (codeload.github.com)... 192.30.255.121
Connecting to codeload.github.com (codeload.github.com)|192.30.255.121|:443... 
connected.
HTTP request sent, awaiting response... 200 OK
Length: unspecified [application/zip]
Saving to: 'libmetal.zip'

libmetal.zip[<=> ]   0  --.-KB/s   
libmetal.zip[ <=>] 375.15K  --.-KB/sin 0.06s   

2020-07-04 05:36:14 (6.05 MB/s) - 'libmetal.zip' saved [384158]

--2020-07-04 05:36:14--  
https://github.com/OpenAMP/open-amp/archive/v2020.04.0.zip
Resolving github.com (g

Re: [DISCUSS] NuttX 9.1 RC1

[Brennan Ashton]

On Fri, Jul 3, 2020 at 7:44 PM Brennan Ashton  wrote:
>
> Haitao,
> Thanks for catching that.  I suspect this might have been around for a
> while in the zip releases.
> The release script checks out a tag to make sure we are getting what
> we expect so I dont think we cut the wrong code
>
> What looks to be going on is we have files in .gitignore that are
> being stripped when zipme.sh calls tar
> ./nuttx/tools/zipme.sh:TAR+=" --exclude-vcs-ignores --exclude-vcs"
> We are also stripping out all the z80 asm files which is really bad.
>
> I did a diff between the tag and the release tarball and I found this
> diff -rq nuttx/ ../incubator-nuttx | grep -v gitignore
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f91_handlers.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f91_init.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_handlers.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_init.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_loader.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_program.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_getsp.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_io.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_irqcommon.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_irqsave.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_progentry.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_reset.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_restorecontext.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_saveusercontext.asm
> Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_startup.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_head.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_restoreusercontext.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_rom.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_romvectors.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_saveusercontext.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_vectcommon.asm
> Only in ../incubator-nuttx/arch/z80/src/z180: z180_vectors.asm
> Only in ../incubator-nuttx/arch/z80/src/z80: z80_head.asm
> Only in ../incubator-nuttx/arch/z80/src/z80: z80_restoreusercontext.asm
> Only in ../incubator-nuttx/arch/z80/src/z80: z80_rom.asm
> Only in ../incubator-nuttx/arch/z80/src/z80: z80_saveusercontext.asm
> Only in ../incubator-nuttx: .asf.yaml
> Only in ../incubator-nuttx/boards/arm/samd5e5/metro-m4/scripts: nvm.srec
> Only in ../incubator-nuttx/boards/arm/samd5e5/same54-xplained-pro/scripts:
> nvm.srec
> Only in ../incubator-nuttx/boards/sim/sim/sim/src/etc: init.d
> Only in ../incubator-nuttx: .git
> Only in ../incubator-nuttx: .github
> Only in nuttx/: .version
>
> Anyone have a suggestion on how to handle this?  I am tempted to
> remove that option.
> That would require making sure the repo is clean.  I do this anyway by
> doing a fresh shallow clone of the repo and checking that the tag is
> exactly matching the commit
>
> --Brennan

Opened an issue in github.
https://github.com/apache/incubator-nuttx/issues/1363

--Brennan

Re: [DISCUSS] NuttX 9.1 RC1

[Brennan Ashton]

Haitao,
Thanks for catching that.  I suspect this might have been around for a
while in the zip releases.
The release script checks out a tag to make sure we are getting what
we expect so I dont think we cut the wrong code

What looks to be going on is we have files in .gitignore that are
being stripped when zipme.sh calls tar
./nuttx/tools/zipme.sh:TAR+=" --exclude-vcs-ignores --exclude-vcs"
We are also stripping out all the z80 asm files which is really bad.

I did a diff between the tag and the release tarball and I found this
diff -rq nuttx/ ../incubator-nuttx | grep -v gitignore
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f91_handlers.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f91_init.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_handlers.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_init.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_loader.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80f92_program.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_getsp.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_io.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_irqcommon.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_irqsave.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_progentry.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_reset.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_restorecontext.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_saveusercontext.asm
Only in ../incubator-nuttx/arch/z80/src/ez80: ez80_startup.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_head.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_restoreusercontext.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_rom.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_romvectors.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_saveusercontext.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_vectcommon.asm
Only in ../incubator-nuttx/arch/z80/src/z180: z180_vectors.asm
Only in ../incubator-nuttx/arch/z80/src/z80: z80_head.asm
Only in ../incubator-nuttx/arch/z80/src/z80: z80_restoreusercontext.asm
Only in ../incubator-nuttx/arch/z80/src/z80: z80_rom.asm
Only in ../incubator-nuttx/arch/z80/src/z80: z80_saveusercontext.asm
Only in ../incubator-nuttx: .asf.yaml
Only in ../incubator-nuttx/boards/arm/samd5e5/metro-m4/scripts: nvm.srec
Only in ../incubator-nuttx/boards/arm/samd5e5/same54-xplained-pro/scripts:
nvm.srec
Only in ../incubator-nuttx/boards/sim/sim/sim/src/etc: init.d
Only in ../incubator-nuttx: .git
Only in ../incubator-nuttx: .github
Only in nuttx/: .version

Anyone have a suggestion on how to handle this?  I am tempted to
remove that option.
That would require making sure the repo is clean.  I do this anyway by
doing a fresh shallow clone of the repo and checking that the tag is
exactly matching the commit

--Brennan

On Fri, Jul 3, 2020 at 7:04 PM Haitao Liu  wrote:
>
> I have just downloaded
> https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC1/ and built
> sim:nsh which reports rcS missing as below.
> But I checked the release/9.1 branch with rcS change inside. So I wonder if
> the 9.1.0-RC1 is not align to the latest 9.1 branch code.
>
> make[1]: Entering directory '/home/haitao/test/nuttx/arch/sim/src'
> make[2]: Entering directory '/home/haitao/test/nuttx/boards/sim/sim/sim/src'
> make[2]: *** No rule to make target 'etc/init.d/rcS', needed by
> 'etctmp/etc/init.d/rcS'.  Stop.
> make[2]: Leaving directory '/home/haitao/test/nuttx/boards/sim/sim/sim/src'
> Makefile:326: recipe for target '.depend' failed
> make[1]: *** [.depend] Error 2
> make[1]: Leaving directory '/home/haitao/test/nuttx/arch/sim/src'
> tools/Makefile.unix:441: recipe for target 'pass2dep' failed
>
> Brennan Ashton  于2020年6月27日周六 上午1:48写道：
>
> > Hey everyone,
> > There were several bugs found on the RC0 so we will not be moving forward
> > with that release candidate and will be creating RC1.  I had suggested a
> > few days ago creating the release today, but as we merged some changes
> > yesterday that seems to be rushed.
> >
> > I'm proposing that we move forward cutting the RC1 on Sunday 28th. I would
> > encourage everyone to test with the fixes that have been backported already
> > to the releases/9.1 branch. I know there is an outstanding bug report that
> > was sent to the list but this is not even in master yet.
> >
> >
> > https://lists.apache.org/x/thread.html/rbb1f85b5f2dba9ee221548fcc5f99d49ef55522c487b99c1549c3a52@%3Cdev.nuttx.apache.org%3E
> >
> >
> > Thanks,
> > Brennan
> >

Re: SVD -> header generator

[Matias N.]

I just added support for bitfields. It defines the _SHIFT, _MASK and specific 
value definitions, as well as description as a comment. I tried to be clever 
about when not to print obvious values and to maintain a reasonable formatting. 
I think it works pretty well. You can see the output for RADIO peripheral here:

https://gist.github.com/v01d/6e5afc8ff922f6d0240c390540f21827

Feel free to submit issues in the gitlab project if you find any problem and 
have a suggestion to improve it.

Best,
Matias

On Fri, Jul 3, 2020, at 21:28, Matias N. wrote:
> I agree with your understanding. I followed the same reasoning. If this data 
> is on a public datasheet, the header is indistinguishable from one manually 
> created from the SVD. Unless the text description of each register is 
> considered
> some kind of original artwork, but that could be even omitted if desired.
> 
> Best,
> Matias
> 
> On Fri, Jul 3, 2020, at 20:52, Gregory Nutt wrote:
>> 
>> > I just looked at that header and looks like a "no warranty" disclaimer. 
>> > Does not impose any restriction on generation code based on that file.
>> 
>> I am not an attorney and not qualified to give a legal opinion. But that 
>> has never stopped me before.
>> 
>> A copyright covers the presentation of a materials, not the content of 
>> materials. If using the same definitions as are provided by one header 
>> file in another header file were a breach of some copyright, the whole 
>> world would be in trouble. 'Wine' duplicates windows definitions for 
>> compatibility. Linux duplicates some BSD definitions for compatibility 
>> for BSD and POSIX definitions compatibility. NuttX duplicates some 
>> Linux definitions for compatibility.
>> 
>> There was a a lawsuit about this several decades ago when when Unix 
>> claimed that it owned all of the Unix interface definitions. That suit 
>> failed and it was ruled that you cannot copyright an interface. So we 
>> are free to define compatible interfaces without concern for copyright 
>> issues.
>> 
>> Another related case had to do with bitmap fonts of traditional fonts 
>> like Times Roman. Scalable fonts can be protected because the scaling 
>> is an algorithm; custom bit map fonts can be protected because they are 
>> original artwork. But bitmaps of traditional fonts cannot be protected 
>> because they are neither.
>> 
>> In my "legal opinion", I would think that that all of these apply. 
>> Register definitions define an interface and that interface is openly 
>> documented in various sources. We know that creating header files from 
>> those openly documented specs is acceptable (we do that all of the 
>> time). So I cannot see that there could be a legal issue with 
>> automatically generating Apache 2.0 header files from those XML files.
>> 
>> You might ask the position of the person that claims ownership of those 
>> XML files, but I cannot see how the license on the XML files that 
>> contain a public interface definition could limit our freedom to 
>> generate our own header files for that public interface provided that we 
>> do not re-distribute the copyrighted XML files. Justin certainly will 
>> have a different opinion.
>> 
>> Greg
>> 
>> 
>> 
>> 
> 

Re: [DISCUSS] NuttX 9.1 RC1

[Haitao Liu]

I have just downloaded
https://dist.apache.org/repos/dist/dev/incubator/nuttx/9.1.0-RC1/ and built
sim:nsh which reports rcS missing as below.
But I checked the release/9.1 branch with rcS change inside. So I wonder if
the 9.1.0-RC1 is not align to the latest 9.1 branch code.

make[1]: Entering directory '/home/haitao/test/nuttx/arch/sim/src'
make[2]: Entering directory '/home/haitao/test/nuttx/boards/sim/sim/sim/src'
make[2]: *** No rule to make target 'etc/init.d/rcS', needed by
'etctmp/etc/init.d/rcS'.  Stop.
make[2]: Leaving directory '/home/haitao/test/nuttx/boards/sim/sim/sim/src'
Makefile:326: recipe for target '.depend' failed
make[1]: *** [.depend] Error 2
make[1]: Leaving directory '/home/haitao/test/nuttx/arch/sim/src'
tools/Makefile.unix:441: recipe for target 'pass2dep' failed

Brennan Ashton  于2020年6月27日周六 上午1:48写道：

> Hey everyone,
> There were several bugs found on the RC0 so we will not be moving forward
> with that release candidate and will be creating RC1.  I had suggested a
> few days ago creating the release today, but as we merged some changes
> yesterday that seems to be rushed.
>
> I'm proposing that we move forward cutting the RC1 on Sunday 28th. I would
> encourage everyone to test with the fixes that have been backported already
> to the releases/9.1 branch. I know there is an outstanding bug report that
> was sent to the list but this is not even in master yet.
>
>
> https://lists.apache.org/x/thread.html/rbb1f85b5f2dba9ee221548fcc5f99d49ef55522c487b99c1549c3a52@%3Cdev.nuttx.apache.org%3E
>
>
> Thanks,
> Brennan
>

Re: SVD -> header generator

[Matias N.]

I agree with your understanding. I followed the same reasoning. If this data is 
on a public datasheet, the header is indistinguishable from one manually 
created from the SVD. Unless the text description of each register is considered
some kind of original artwork, but that could be even omitted if desired.

Best,
Matias

On Fri, Jul 3, 2020, at 20:52, Gregory Nutt wrote:
> 
> > I just looked at that header and looks like a "no warranty" disclaimer. 
> > Does not impose any restriction on generation code based on that file.
> 
> I am not an attorney and not qualified to give a legal opinion. But that 
> has never stopped me before.
> 
> A copyright covers the presentation of a materials, not the content of 
> materials. If using the same definitions as are provided by one header 
> file in another header file were a breach of some copyright, the whole 
> world would be in trouble. 'Wine' duplicates windows definitions for 
> compatibility. Linux duplicates some BSD definitions for compatibility 
> for BSD and POSIX definitions compatibility. NuttX duplicates some 
> Linux definitions for compatibility.
> 
> There was a a lawsuit about this several decades ago when when Unix 
> claimed that it owned all of the Unix interface definitions. That suit 
> failed and it was ruled that you cannot copyright an interface. So we 
> are free to define compatible interfaces without concern for copyright 
> issues.
> 
> Another related case had to do with bitmap fonts of traditional fonts 
> like Times Roman. Scalable fonts can be protected because the scaling 
> is an algorithm; custom bit map fonts can be protected because they are 
> original artwork. But bitmaps of traditional fonts cannot be protected 
> because they are neither.
> 
> In my "legal opinion", I would think that that all of these apply. 
> Register definitions define an interface and that interface is openly 
> documented in various sources. We know that creating header files from 
> those openly documented specs is acceptable (we do that all of the 
> time). So I cannot see that there could be a legal issue with 
> automatically generating Apache 2.0 header files from those XML files.
> 
> You might ask the position of the person that claims ownership of those 
> XML files, but I cannot see how the license on the XML files that 
> contain a public interface definition could limit our freedom to 
> generate our own header files for that public interface provided that we 
> do not re-distribute the copyrighted XML files. Justin certainly will 
> have a different opinion.
> 
> Greg
> 
> 
> 
> 

Re: SVD -> header generator

[Gregory Nutt]

I just looked at that header and looks like a "no warranty" disclaimer. Does 
not impose any restriction on generation code based on that file.


I am not an attorney and not qualified to give a legal opinion. But that 
has never stopped me before.


A copyright covers the presentation of a materials, not the content of 
materials. If using the same definitions as are provided by one header 
file in another header file were a breach of some copyright, the whole 
world would be in trouble.  'Wine' duplicates windows definitions for 
compatibility.  Linux duplicates some BSD definitions for compatibility 
for BSD and POSIX definitions compatibility.  NuttX duplicates some 
Linux definitions for compatibility.


There was a a lawsuit about this several decades ago when when Unix 
claimed that it owned all of the Unix interface definitions. That suit 
failed and it was ruled that you cannot copyright an interface.  So we 
are free to define compatible interfaces without concern for copyright 
issues.


Another related case had to do with bitmap fonts of traditional fonts 
like Times Roman.  Scalable fonts can be protected because the scaling 
is an algorithm; custom bit map fonts can be protected because they are 
original artwork.  But bitmaps of traditional fonts cannot be protected 
because they are neither.


In my "legal opinion", I would think that that all of these apply.  
Register definitions define an interface and that interface is openly 
documented in various sources.  We know that creating header files from 
those openly documented specs is acceptable (we do that all of the 
time).  So I cannot see that there could be a legal  issue with 
automatically generating Apache 2.0 header files from those XML files.


You might ask the position of the person that claims ownership of those 
XML files, but I cannot see how the license on the XML files that 
contain a public interface definition could limit our freedom to 
generate our own header files for that public interface provided that we 
do not re-distribute the copyrighted XML files. Justin certainly will 
have a different opinion.


Greg

Re: SVD -> header generator

[Brennan Ashton]

Both of these I also linked are far more restrictive:

https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html

TI is another example with further restrictions.
https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd

--Brennan


On Fri, Jul 3, 2020, 4:29 PM Matias N.  wrote:

> I just looked at that header and looks like a "no warranty" disclaimer.
> Does not impose any restriction on generation code based on that file.
>
> On Fri, Jul 3, 2020, at 18:25, Brennan Ashton wrote:
> > Just a warning on generating code from these files. Many of the have
> > explicit restrictions on using them which may not be compatible with BSD
> or
> > Apache. For example NXP
> >
> https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
> >
> > I'm not sure on the legal side about this but it is why I have avoiding
> > using them to generate headers. Maybe Apache Legal could give us
> guidance.
> >
> > --Brennan
> >
> > On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
> >
> > > Hi,
> > > I thought about doing this for a long time and I just did it, wasn't
> > > really hard.
> > > If you're not aware, CMSIS-SVD file format is an XML based definitions
> of
> > > peripherals and registers available in a given MCU. This is typically
> used
> > > for debugging but it is quite useful for generating header
> definitions. I
> > > wrote a quick python script that is able to generate register
> definitions
> > > and base addresses of peripherals. It is based on
> > > https://github.com/posborne/cmsis-svd which includes both the SVD
> python
> > > parser and a really complete database of SVD files.
> > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen
> (be
> > > sure to check the README on how to use)
> > >
> > > Example output (the console output properly tabulates data, format may
> > > look broken in the email):
> > >
> > > Generate memory map:
> > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> > >
> > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > > ... etc
> > >
> > > Register definitions:
> > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> > >
> > > /* Register offsets
> > > */
> > >
> > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > > mode.*/
> > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > > mode.*/
> > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > > ... etc
> > >
> > > /* Register definitions
> > > */
> > >
> > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_START_OFFSET)
> > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_STOP_OFFSET)
> > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > > ... etc
> > >
> > > Best,
> > > Matias
> >
>

Re: SVD -> header generator

[Matias N.]

I just looked at that header and looks like a "no warranty" disclaimer. Does 
not impose any restriction on generation code based on that file. 

On Fri, Jul 3, 2020, at 18:25, Brennan Ashton wrote:
> Just a warning on generating code from these files. Many of the have
> explicit restrictions on using them which may not be compatible with BSD or
> Apache. For example NXP
> https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
> 
> I'm not sure on the legal side about this but it is why I have avoiding
> using them to generate headers. Maybe Apache Legal could give us guidance.
> 
> --Brennan
> 
> On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
> 
> > Hi,
> > I thought about doing this for a long time and I just did it, wasn't
> > really hard.
> > If you're not aware, CMSIS-SVD file format is an XML based definitions of
> > peripherals and registers available in a given MCU. This is typically used
> > for debugging but it is quite useful for generating header definitions. I
> > wrote a quick python script that is able to generate register definitions
> > and base addresses of peripherals. It is based on
> > https://github.com/posborne/cmsis-svd which includes both the SVD python
> > parser and a really complete database of SVD files.
> > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> > sure to check the README on how to use)
> >
> > Example output (the console output properly tabulates data, format may
> > look broken in the email):
> >
> > Generate memory map:
> > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> >
> > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > ... etc
> >
> > Register definitions:
> > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> >
> > /* Register offsets
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > mode.*/
> > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > mode.*/
> > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > ... etc
> >
> > /* Register definitions
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_START_OFFSET)
> > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_STOP_OFFSET)
> > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > ... etc
> >
> > Best,
> > Matias
> 

RE: SVD -> header generator

[David Sidrane]

Hi Matias,

> I thought about doing this for a long time

Yes So many times...Thank you for doing it!

David

-Original Message-
From: Matias N. [mailto:mat...@imap.cc]
Sent: Friday, July 03, 2020 1:45 PM
To: dev@nuttx.apache.org
Subject: SVD -> header generator

Hi,
I thought about doing this for a long time and I just did it, wasn't
really hard.
If you're not aware, CMSIS-SVD file format is an XML based definitions of
peripherals and registers available in a given MCU. This is typically used
for debugging but it is quite useful for generating header definitions. I
wrote a quick python script that is able to generate register definitions
and base addresses of peripherals. It is based on
https://github.com/posborne/cmsis-svd which includes both the SVD python
parser and a really complete database of SVD files.
The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
sure to check the README on how to use)

Example output (the console output properly tabulates data, format may
look broken in the email):

Generate memory map:
$ ./gen.py -v Nordic -d nrf51 -p map -x NRF51

#define NRF51_POWER_BASE 0x4000 /* Power Control.*/
#define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
#define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
#define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
... etc

Register definitions:
$ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51

/* Register offsets
*/

#define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
mode.*/
#define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
mode.*/
#define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
#define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
#define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
... etc

/* Register definitions
*/

#define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_TXEN_OFFSET)
#define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_RXEN_OFFSET)
#define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_START_OFFSET)
#define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_STOP_OFFSET)
#define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_DISABLE_OFFSET)
#define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_RSSISTART_OFFSET)
#define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
... etc

Best,
Matias

Re: SVD -> header generator

[Matias N.]

It seems really strange to me that the output file of a code generator tool is 
something that would be within the scope of a license of the SVD file itself. 
If I were to write that same output myself by hand what would be different? 
Anyway, we can look further into the validity of that licensing restriction 
before using it.

Regarding bitfields, it is indeed possible since they are part of the SVD 
files. I just haven't worked on that yet. I will look into it.

Best,
Matias

On Fri, Jul 3, 2020, at 19:35, Adam Feuer wrote:
> Brennan,
> 
> Ah, I see. The data files all have their own individual licenses, yes, some
> are not open source. Ugh.
> 
> Yeah, I wouldn't use a tool to generate it unless the data file was using a
> compatible license...
> 
> -adam
> 
> On Fri, Jul 3, 2020 at 3:30 PM Brennan Ashton 
> wrote:
> 
> > They are not all Apache 2.0. The NXP ones are a mixed bag, some call
> > out BSD, some just liability disclaimer, looks like the example I gave
> > was not the best one.
> >
> > For STM this file is restricted in a way that is not compatible.
> > Personally I think that is a mistake on the part of STM, but here we
> > are...
> >
> > https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html
> >
> > TI is another example with further restrictions.
> >
> > https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd
> >
> > --Brennan
> >
> > On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer  wrote:
> > >
> > > Brennan,
> > >
> > > All the files in this repo are Apache 2.0 licensed:
> > >
> > > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE
> > >
> > > Doesn't that cover the license issue? The header is only a liability
> > > disclaimer.
> > >
> > > -adam
> > >
> > >
> > >
> > > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton  > >
> > > wrote:
> > >
> > > > Just a warning on generating code from these files. Many of the have
> > > > explicit restrictions on using them which may not be compatible with
> > BSD or
> > > > Apache. For example NXP
> > > >
> > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
> > > >
> > > > I'm not sure on the legal side about this but it is why I have avoiding
> > > > using them to generate headers. Maybe Apache Legal could give us
> > guidance.
> > > >
> > > > --Brennan
> > > >
> > > > On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
> > > >
> > > > > Hi,
> > > > > I thought about doing this for a long time and I just did it, wasn't
> > > > > really hard.
> > > > > If you're not aware, CMSIS-SVD file format is an XML based
> > definitions of
> > > > > peripherals and registers available in a given MCU. This is typically
> > > > used
> > > > > for debugging but it is quite useful for generating header
> > definitions. I
> > > > > wrote a quick python script that is able to generate register
> > definitions
> > > > > and base addresses of peripherals. It is based on
> > > > > https://github.com/posborne/cmsis-svd which includes both the SVD
> > python
> > > > > parser and a really complete database of SVD files.
> > > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen
> > (be
> > > > > sure to check the README on how to use)
> > > > >
> > > > > Example output (the console output properly tabulates data, format
> > may
> > > > > look broken in the email):
> > > > >
> > > > > Generate memory map:
> > > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> > > > >
> > > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > > > > ... etc
> > > > >
> > > > > Register definitions:
> > > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> > > > >
> > > > > /* Register offsets
> > > > > */
> > > > >
> > > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > > > > mode.*/
> > > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > > > > mode.*/
> > > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > > > > ... etc
> > > > >
> > > > > /* Register definitions
> > > > > */
> > > > >
> > > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > > > > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > > > > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > > > > NRF51_RADIO_TASKS_START_OFFSET)
> > > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > > > > NRF51_RADIO_TASKS_STOP_OFFSET)
> > > > > #define NRF51_RADIO_TA

Re: SVD -> header generator

[Adam Feuer]

Brennan,

Ah, I see. The data files all have their own individual licenses, yes, some
are not open source. Ugh.

Yeah, I wouldn't use a tool to generate it unless the data file was using a
compatible license...

-adam

On Fri, Jul 3, 2020 at 3:30 PM Brennan Ashton 
wrote:

> They are not all Apache 2.0. The NXP ones are a mixed bag, some call
> out BSD, some just liability disclaimer, looks like the example I gave
> was not the best one.
>
> For STM this file is restricted in a way that is not compatible.
> Personally I think that is a mistake on the part of STM, but here we
> are...
>
> https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html
>
> TI is another example with further restrictions.
>
> https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd
>
> --Brennan
>
> On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer  wrote:
> >
> > Brennan,
> >
> > All the files in this repo are Apache 2.0 licensed:
> >
> > https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE
> >
> > Doesn't that cover the license issue? The header is only a liability
> > disclaimer.
> >
> > -adam
> >
> >
> >
> > On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton  >
> > wrote:
> >
> > > Just a warning on generating code from these files. Many of the have
> > > explicit restrictions on using them which may not be compatible with
> BSD or
> > > Apache.  For example NXP
> > >
> https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
> > >
> > > I'm not sure on the legal side about this but it is why I have avoiding
> > > using them to generate headers. Maybe Apache Legal could give us
> guidance.
> > >
> > > --Brennan
> > >
> > > On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
> > >
> > > > Hi,
> > > > I thought about doing this for a long time and I just did it, wasn't
> > > > really hard.
> > > > If you're not aware, CMSIS-SVD file format is an XML based
> definitions of
> > > > peripherals and registers available in a given MCU. This is typically
> > > used
> > > > for debugging but it is quite useful for generating header
> definitions. I
> > > > wrote a quick python script that is able to generate register
> definitions
> > > > and base addresses of peripherals. It is based on
> > > > https://github.com/posborne/cmsis-svd which includes both the SVD
> python
> > > > parser and a really complete database of SVD files.
> > > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen
> (be
> > > > sure to check the README on how to use)
> > > >
> > > > Example output (the console output properly tabulates data, format
> may
> > > > look broken in the email):
> > > >
> > > > Generate memory map:
> > > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> > > >
> > > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > > > ... etc
> > > >
> > > > Register definitions:
> > > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> > > >
> > > > /* Register offsets
> > > > */
> > > >
> > > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > > > mode.*/
> > > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > > > mode.*/
> > > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > > > ... etc
> > > >
> > > > /* Register definitions
> > > > */
> > > >
> > > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_START_OFFSET)
> > > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_STOP_OFFSET)
> > > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > > > ... etc
> > > >
> > > > Best,
> > > > Matias
> > >
> >
> >
> > --
> > Adam Feuer 
>


-- 
Adam Feuer 

Re: SVD -> header generator

[Brennan Ashton]

They are not all Apache 2.0. The NXP ones are a mixed bag, some call
out BSD, some just liability disclaimer, looks like the example I gave
was not the best one.

For STM this file is restricted in a way that is not compatible.
Personally I think that is a mistake on the part of STM, but here we
are...
https://raw.githubusercontent.com/posborne/cmsis-svd/master/data/STMicro/License.html

TI is another example with further restrictions.
https://github.com/posborne/cmsis-svd/blob/master/data/TexasInstruments/TM4C123GH6ZRB.svd

--Brennan

On Fri, Jul 3, 2020 at 3:19 PM Adam Feuer  wrote:
>
> Brennan,
>
> All the files in this repo are Apache 2.0 licensed:
>
> https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE
>
> Doesn't that cover the license issue? The header is only a liability
> disclaimer.
>
> -adam
>
>
>
> On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton 
> wrote:
>
> > Just a warning on generating code from these files. Many of the have
> > explicit restrictions on using them which may not be compatible with BSD or
> > Apache.  For example NXP
> > https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
> >
> > I'm not sure on the legal side about this but it is why I have avoiding
> > using them to generate headers. Maybe Apache Legal could give us guidance.
> >
> > --Brennan
> >
> > On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
> >
> > > Hi,
> > > I thought about doing this for a long time and I just did it, wasn't
> > > really hard.
> > > If you're not aware, CMSIS-SVD file format is an XML based definitions of
> > > peripherals and registers available in a given MCU. This is typically
> > used
> > > for debugging but it is quite useful for generating header definitions. I
> > > wrote a quick python script that is able to generate register definitions
> > > and base addresses of peripherals. It is based on
> > > https://github.com/posborne/cmsis-svd which includes both the SVD python
> > > parser and a really complete database of SVD files.
> > > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> > > sure to check the README on how to use)
> > >
> > > Example output (the console output properly tabulates data, format may
> > > look broken in the email):
> > >
> > > Generate memory map:
> > > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> > >
> > > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > > ... etc
> > >
> > > Register definitions:
> > > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> > >
> > > /* Register offsets
> > > */
> > >
> > > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > > mode.*/
> > > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > > mode.*/
> > > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > > ... etc
> > >
> > > /* Register definitions
> > > */
> > >
> > > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_START_OFFSET)
> > > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_STOP_OFFSET)
> > > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > > ... etc
> > >
> > > Best,
> > > Matias
> >
>
>
> --
> Adam Feuer 

Re: SVD -> header generator

[Adam Feuer]

Brennan,

All the files in this repo are Apache 2.0 licensed:

https://github.com/posborne/cmsis-svd/blob/master/LICENSE-APACHE

Doesn't that cover the license issue? The header is only a liability
disclaimer.

-adam



On Fri, Jul 3, 2020 at 2:25 PM Brennan Ashton 
wrote:

> Just a warning on generating code from these files. Many of the have
> explicit restrictions on using them which may not be compatible with BSD or
> Apache.  For example NXP
> https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd
>
> I'm not sure on the legal side about this but it is why I have avoiding
> using them to generate headers. Maybe Apache Legal could give us guidance.
>
> --Brennan
>
> On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:
>
> > Hi,
> > I thought about doing this for a long time and I just did it, wasn't
> > really hard.
> > If you're not aware, CMSIS-SVD file format is an XML based definitions of
> > peripherals and registers available in a given MCU. This is typically
> used
> > for debugging but it is quite useful for generating header definitions. I
> > wrote a quick python script that is able to generate register definitions
> > and base addresses of peripherals. It is based on
> > https://github.com/posborne/cmsis-svd which includes both the SVD python
> > parser and a really complete database of SVD files.
> > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> > sure to check the README on how to use)
> >
> > Example output (the console output properly tabulates data, format may
> > look broken in the email):
> >
> > Generate memory map:
> > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> >
> > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > ... etc
> >
> > Register definitions:
> > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> >
> > /* Register offsets
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > mode.*/
> > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > mode.*/
> > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > ... etc
> >
> > /* Register definitions
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_START_OFFSET)
> > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_STOP_OFFSET)
> > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > ... etc
> >
> > Best,
> > Matias
>


-- 
Adam Feuer 

Re: SVD -> header generator

[Brennan Ashton]

Just a warning on generating code from these files. Many of the have
explicit restrictions on using them which may not be compatible with BSD or
Apache.  For example NXP
https://github.com/posborne/cmsis-svd/blob/master/data/NXP/LPC1102_4_v4.svd

I'm not sure on the legal side about this but it is why I have avoiding
using them to generate headers. Maybe Apache Legal could give us guidance.

--Brennan

On Fri, Jul 3, 2020, 1:45 PM Matias N.  wrote:

> Hi,
> I thought about doing this for a long time and I just did it, wasn't
> really hard.
> If you're not aware, CMSIS-SVD file format is an XML based definitions of
> peripherals and registers available in a given MCU. This is typically used
> for debugging but it is quite useful for generating header definitions. I
> wrote a quick python script that is able to generate register definitions
> and base addresses of peripherals. It is based on
> https://github.com/posborne/cmsis-svd which includes both the SVD python
> parser and a really complete database of SVD files.
> The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> sure to check the README on how to use)
>
> Example output (the console output properly tabulates data, format may
> look broken in the email):
>
> Generate memory map:
> $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
>
> #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> ... etc
>
> Register definitions:
> $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
>
> /* Register offsets
> */
>
> #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> mode.*/
> #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> mode.*/
> #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> ... etc
>
> /* Register definitions
> */
>
> #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_TXEN_OFFSET)
> #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RXEN_OFFSET)
> #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_START_OFFSET)
> #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_STOP_OFFSET)
> #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_DISABLE_OFFSET)
> #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> ... etc
>
> Best,
> Matias

Re: SVD -> header generator

[Alan Carvalho de Assis]

Very good Matias!

Indeed, registers definition is a boring part of creating a new NuttX
port, your tool makes it a breeze!

BR,

Alan

On 7/3/20, Adam Feuer  wrote:
> Matias,
>
> This looks like it would be a lot of help bringing NuttX up on a new
> microprocessor. Thanks!
>
> -adam
>
> On Fri, Jul 3, 2020 at 1:46 PM Matias N.  wrote:
>
>> Hi,
>> I thought about doing this for a long time and I just did it, wasn't
>> really hard.
>> If you're not aware, CMSIS-SVD file format is an XML based definitions of
>> peripherals and registers available in a given MCU. This is typically
>> used
>> for debugging but it is quite useful for generating header definitions. I
>> wrote a quick python script that is able to generate register definitions
>> and base addresses of peripherals. It is based on
>> https://github.com/posborne/cmsis-svd which includes both the SVD python
>> parser and a really complete database of SVD files.
>> The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
>> sure to check the README on how to use)
>>
>> Example output (the console output properly tabulates data, format may
>> look broken in the email):
>>
>> Generate memory map:
>> $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
>>
>> #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
>> #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
>> #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
>> #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
>> ... etc
>>
>> Register definitions:
>> $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
>>
>> /* Register offsets
>> */
>>
>> #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
>> mode.*/
>> #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
>> mode.*/
>> #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
>> #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
>> #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
>> ... etc
>>
>> /* Register definitions
>> */
>>
>> #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_TXEN_OFFSET)
>> #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_RXEN_OFFSET)
>> #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_START_OFFSET)
>> #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_STOP_OFFSET)
>> #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_DISABLE_OFFSET)
>> #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_RSSISTART_OFFSET)
>> #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
>> NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
>> ... etc
>>
>> Best,
>> Matias
>
>
>
> --
> Adam Feuer 
>

Re: SVD -> header generator

[Abdelatif Guettouche]

That's a great one!
Does it do bitfields?  I gave it a quick try and I only got register
definitions.

Regardless, that could be a great time saver!

On Fri, Jul 3, 2020 at 9:57 PM Adam Feuer  wrote:
>
> Matias,
>
> This looks like it would be a lot of help bringing NuttX up on a new
> microprocessor. Thanks!
>
> -adam
>
> On Fri, Jul 3, 2020 at 1:46 PM Matias N.  wrote:
>
> > Hi,
> > I thought about doing this for a long time and I just did it, wasn't
> > really hard.
> > If you're not aware, CMSIS-SVD file format is an XML based definitions of
> > peripherals and registers available in a given MCU. This is typically used
> > for debugging but it is quite useful for generating header definitions. I
> > wrote a quick python script that is able to generate register definitions
> > and base addresses of peripherals. It is based on
> > https://github.com/posborne/cmsis-svd which includes both the SVD python
> > parser and a really complete database of SVD files.
> > The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> > sure to check the README on how to use)
> >
> > Example output (the console output properly tabulates data, format may
> > look broken in the email):
> >
> > Generate memory map:
> > $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
> >
> > #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> > #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> > #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> > #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> > ... etc
> >
> > Register definitions:
> > $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
> >
> > /* Register offsets
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> > mode.*/
> > #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> > mode.*/
> > #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> > #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> > #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> > ... etc
> >
> > /* Register definitions
> > */
> >
> > #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_TXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RXEN_OFFSET)
> > #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_START_OFFSET)
> > #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_STOP_OFFSET)
> > #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_DISABLE_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> > #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> > NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> > ... etc
> >
> > Best,
> > Matias
>
>
>
> --
> Adam Feuer 

Re: SVD -> header generator

[Adam Feuer]

Matias,

This looks like it would be a lot of help bringing NuttX up on a new
microprocessor. Thanks!

-adam

On Fri, Jul 3, 2020 at 1:46 PM Matias N.  wrote:

> Hi,
> I thought about doing this for a long time and I just did it, wasn't
> really hard.
> If you're not aware, CMSIS-SVD file format is an XML based definitions of
> peripherals and registers available in a given MCU. This is typically used
> for debugging but it is quite useful for generating header definitions. I
> wrote a quick python script that is able to generate register definitions
> and base addresses of peripherals. It is based on
> https://github.com/posborne/cmsis-svd which includes both the SVD python
> parser and a really complete database of SVD files.
> The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be
> sure to check the README on how to use)
>
> Example output (the console output properly tabulates data, format may
> look broken in the email):
>
> Generate memory map:
> $ ./gen.py -v Nordic -d nrf51 -p map -x NRF51
>
> #define NRF51_POWER_BASE 0x4000 /* Power Control.*/
> #define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
> #define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
> #define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
> ... etc
>
> Register definitions:
> $ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51
>
> /* Register offsets
> */
>
> #define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX
> mode.*/
> #define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX
> mode.*/
> #define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
> #define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
> #define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
> ... etc
>
> /* Register definitions
> */
>
> #define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_TXEN_OFFSET)
> #define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RXEN_OFFSET)
> #define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_START_OFFSET)
> #define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_STOP_OFFSET)
> #define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_DISABLE_OFFSET)
> #define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RSSISTART_OFFSET)
> #define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE +
> NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
> ... etc
>
> Best,
> Matias



-- 
Adam Feuer 

SVD -> header generator

[Matias N.]

Hi,
I thought about doing this for a long time and I just did it, wasn't really 
hard.
If you're not aware, CMSIS-SVD file format is an XML based definitions of 
peripherals and registers available in a given MCU. This is typically used for 
debugging but it is quite useful for generating header definitions. I wrote a 
quick python script that is able to generate register definitions and base 
addresses of peripherals. It is based on https://github.com/posborne/cmsis-svd 
which includes both the SVD python parser and a really complete database of SVD 
files.
The tool is available here: https://gitlab.com/nuttx_projects/svdgen (be sure 
to check the README on how to use)

Example output (the console output properly tabulates data, format may look 
broken in the email):

Generate memory map:
$ ./gen.py -v Nordic -d nrf51 -p map -x NRF51

#define NRF51_POWER_BASE 0x4000 /* Power Control.*/
#define NRF51_CLOCK_BASE 0x4000 /* Clock control.*/
#define NRF51_MPU_BASE 0x4000 /* Memory Protection Unit.*/
#define NRF51_AMLI_BASE 0x4000 /* AHB Multi-Layer Interface.*/
... etc

Register definitions:
$ ./gen.py -v Nordic -d nrf51 -p RADIO -x NRF51

/* Register offsets */

#define NRF51_RADIO_TASKS_TXEN_OFFSET 0x00 /* Enable radio in TX mode.*/
#define NRF51_RADIO_TASKS_RXEN_OFFSET 0x04 /* Enable radio in RX mode.*/
#define NRF51_RADIO_TASKS_START_OFFSET 0x08 /* Start radio.*/
#define NRF51_RADIO_TASKS_STOP_OFFSET 0x0c /* Stop radio.*/
#define NRF51_RADIO_TASKS_DISABLE_OFFSET 0x10 /* Disable radio.*/
... etc

/* Register definitions */

#define NRF51_RADIO_TASKS_TXEN (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_TXEN_OFFSET)
#define NRF51_RADIO_TASKS_RXEN (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_RXEN_OFFSET)
#define NRF51_RADIO_TASKS_START (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_START_OFFSET)
#define NRF51_RADIO_TASKS_STOP (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_STOP_OFFSET)
#define NRF51_RADIO_TASKS_DISABLE (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_DISABLE_OFFSET)
#define NRF51_RADIO_TASKS_RSSISTART (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_RSSISTART_OFFSET)
#define NRF51_RADIO_TASKS_RSSISTOP (NRF51_RADIO_BASE + 
NRF51_RADIO_TASKS_RSSISTOP_OFFSET)
... etc

Best,
Matias

Re: Scheduling work from a worker using the same work_s

[Anthony Merlino]

Ok great, thanks Greg!



On Fri, Jul 3, 2020 at 1:13 PM Gregory Nutt  wrote:

>
> > I have a few spots in my code where I am doing something, and I'm just
> now
> > realizing I'm not explicitly sure if it's supported or not.
> >
> > Here is my question:
> >
> > Can work_queue be called from within a worker function that uses the same
> > work_s struct?
> Yes.
> > The documentation only says that if there is existing work, it will be
> > replaced. But what happens if there is existing work, AND it's currently
> > running?
> >
> > I have a few areas where I'm doing it, and it does seem to be working,
> but
> > I'm not sure if there are any race conditions or other considerations
> that
> > I'm not aware of.
>
> That would be clearer if that read "pending" or "queued" work instead of
> "existing" work.  The data in the work queue structures is decanted when
> the work starts:
>
> 128   /* Remove the ready-to-execute work from the list */
> 129
> 130   dq_rem((struct dq_entry_s *)work, &wqueue->q);
> 131
> 132   /* Extract the work description from the entry (in
> case the work
> 133* instance by the re-used after it has been de-queued).
> 134*/
> 135
> 136   worker = work->worker;
> 137
> 138   /* Check for a race condition where the work may be
> nullified
> 139* before it is removed from the queue.
> 140*/
> 141
> 142   if (worker != NULL)
> 143 {
> 144   /* Extract the work argument (before re-enabling
> interrupts) */
> 145
> 146   arg = work->arg;
> 147
> 148   /* Mark the work as no longer being queued */
> 149
> 150   work->worker = NULL;
> 151
> 152   /* Do the work.  Re-enable interrupts while the
> work is being
> 153* performed... we don't have any idea how long
> this will take!
> 154*/
> 155
> 156   leave_critical_section(flags);
> 157   worker(arg);
> 158
> 159   /* Now, unfortunately, since we re-enabled
> interrupts we don't
> 160* know the state of the work list and we will
> have to start
> 161* back at the head of the list.
> 162*/
> 163
> 164   flags = enter_critical_section();
> 165   work  = (FAR struct work_s *)wqueue->q.head;
> 166 }
>
> So the work is no longer queued with the worker function executes.
>
> Greg
>
>
>

Re: Scheduling work from a worker using the same work_s

[Gregory Nutt]

I have a few spots in my code where I am doing something, and I'm just now
realizing I'm not explicitly sure if it's supported or not.

Here is my question:

Can work_queue be called from within a worker function that uses the same
work_s struct?

Yes.

The documentation only says that if there is existing work, it will be
replaced. But what happens if there is existing work, AND it's currently
running?

I have a few areas where I'm doing it, and it does seem to be working, but
I'm not sure if there are any race conditions or other considerations that
I'm not aware of.


That would be clearer if that read "pending" or "queued" work instead of 
"existing" work.  The data in the work queue structures is decanted when 
the work starts:


   128   /* Remove the ready-to-execute work from the list */
   129
   130   dq_rem((struct dq_entry_s *)work, &wqueue->q);
   131
   132   /* Extract the work description from the entry (in
   case the work
   133    * instance by the re-used after it has been de-queued).
   134    */
   135
   136   worker = work->worker;
   137
   138   /* Check for a race condition where the work may be
   nullified
   139    * before it is removed from the queue.
   140    */
   141
   142   if (worker != NULL)
   143 {
   144   /* Extract the work argument (before re-enabling
   interrupts) */
   145
   146   arg = work->arg;
   147
   148   /* Mark the work as no longer being queued */
   149
   150   work->worker = NULL;
   151
   152   /* Do the work.  Re-enable interrupts while the
   work is being
   153    * performed... we don't have any idea how long
   this will take!
   154    */
   155
   156   leave_critical_section(flags);
   157   worker(arg);
   158
   159   /* Now, unfortunately, since we re-enabled
   interrupts we don't
   160    * know the state of the work list and we will
   have to start
   161    * back at the head of the list.
   162    */
   163
   164   flags = enter_critical_section();
   165   work  = (FAR struct work_s *)wqueue->q.head;
   166 }

So the work is no longer queued with the worker function executes.

Greg

Re: BBC MicroBit (nRF51822) running NuttX

[Matias N.]

On Fri, Jul 3, 2020, at 13:32, Alan Carvalho de Assis wrote:
> Hi Saito-san,
> 
> You did an amazing work!
> 
> I found you project by chance, I was searching for NuttX on Twitter
> and found it.
> 
> Maybe the I2C and SPI from nRF51 are similar to nRF52, so we could to
> reuse it. I didn't compare them yet. Matias, did you?

No idea, there may be some differences but I expect most peripherals to be very 
similar. I actually wonder how should this be dealt with, since nrf51/nrf52 are 
very different in terms of ARM architecture but there will probably be a lot of 
common code. 

> BR,
> 
> Alan
> 
> On 7/3/20, saito yutaka  wrote:
> > Hello.
> >
> > Thanks for mail about my project.
> >
> > I don't have much knowledge of the real time os, so I'm writing code while
> > looking it up.
> >
> > I've been able to confirm that Hello World works on micro:bit.
> > And I could debug on micro:bit using gdb and pyocd.
> >
> > I haven't done other things such as lighting of the LED.
> >
> > Thanks
> > Saito Yutaka
> >
> >
> > 2020年7月3日(金) 23:42 Matias N. :
> >
> >> Hi,
> >> I can take a look and see if this would work on my nrf51822. Stil, it
> >> would be better to have
> >> the code author prepare a PR against NuttX. I see recent commits so it
> >> appears an actively maintained
> >> WIP.
> >>
> >> On a related subject: I have ordered an NRF52832 board and module, for
> >> which my ultimate intentions would be to have NuttX support for RADIO
> >> peripheral (as was discussed recently on the list). Since the board will
> >> take some time to arrive and since it appears that NRF51822 RADIO
> >> peripheral is mostly compatible, I could slowly start to work on it
> >> (assuming this NRF51822 port is usable to do so).
> >>
> >> Again, I would learn Bluetooth low-level stuff on the way. I don't mind
> >> this, but of course if someone else is working/planning to work on this
> >> it
> >> would be good to align efforts to avoid duplicate and wasted work.
> >>
> >> Alan, if you haven't contacted the code author we could send him an
> >> email.
> >>
> >> Best,
> >> Matias
> >>
> >> On Thu, Jul 2, 2020, at 19:43, Alan Carvalho de Assis wrote:
> >> > Hi Everyone,
> >> >
> >> > It appears that someone is porting NuttX to BBC MicroBit board
> >> >
> >> > https://github.com/SaitoYutaka/incubator-nuttx
> >> >
> >> > Very interesting!
> >> >
> >> > He is testing on QEMU, maybe someone with an nRF51822 board could give
> >> > it a try! ;-)
> >> >
> >> > BR,
> >> >
> >> > Alan
> >> >
> >>
> >
> 

Re: BBC MicroBit (nRF51822) running NuttX

[Alan Carvalho de Assis]

Hi Saito-san,

You did an amazing work!

I found you project by chance, I was searching for NuttX on Twitter
and found it.

Maybe the I2C and SPI from nRF51 are similar to nRF52, so we could to
reuse it. I didn't compare them yet. Matias, did you?

BR,

Alan

On 7/3/20, saito yutaka  wrote:
> Hello.
>
> Thanks for mail about my project.
>
> I don't have much knowledge of the real time os, so I'm writing code while
> looking it up.
>
> I've been able to confirm that Hello World works on micro:bit.
> And I could debug on micro:bit using gdb and pyocd.
>
> I haven't done other things such as lighting of the LED.
>
> Thanks
> Saito Yutaka
>
>
> 2020年7月3日(金) 23:42 Matias N. :
>
>> Hi,
>> I can take a look and see if this would work on my nrf51822. Stil, it
>> would be better to have
>> the code author prepare a PR against NuttX. I see recent commits so it
>> appears an actively maintained
>> WIP.
>>
>> On a related subject: I have ordered an NRF52832 board and module, for
>> which my ultimate intentions would be to have NuttX support for RADIO
>> peripheral (as was discussed recently on the list). Since the board will
>> take some time to arrive and since it appears that NRF51822 RADIO
>> peripheral is mostly compatible, I could slowly start to work on it
>> (assuming this NRF51822 port is usable to do so).
>>
>> Again, I would learn Bluetooth low-level stuff on the way. I don't mind
>> this, but of course if someone else is working/planning to work on this
>> it
>> would be good to align efforts to avoid duplicate and wasted work.
>>
>> Alan, if you haven't contacted the code author we could send him an
>> email.
>>
>> Best,
>> Matias
>>
>> On Thu, Jul 2, 2020, at 19:43, Alan Carvalho de Assis wrote:
>> > Hi Everyone,
>> >
>> > It appears that someone is porting NuttX to BBC MicroBit board
>> >
>> > https://github.com/SaitoYutaka/incubator-nuttx
>> >
>> > Very interesting!
>> >
>> > He is testing on QEMU, maybe someone with an nRF51822 board could give
>> > it a try! ;-)
>> >
>> > BR,
>> >
>> > Alan
>> >
>>
>

Re: BBC MicroBit (nRF51822) running NuttX

[Matias N.]

Hello Saito,
I just tested your code on my nrf51822 module and, after changing RX/TX pin 
definitions, I get console output. So I confirm your port is functional on real 
board. It would be cool if you could submit a PR against NuttX with your 
changes. I could try to work on it a bit as well, since I'm interested in the 
RADIO peripheral working in NuttX.

Best,
Matias

On Fri, Jul 3, 2020, at 12:41, saito yutaka wrote:
> Hello.
> 
> Thanks for mail about my project.
> 
> I don't have much knowledge of the real time os, so I'm writing code while
> looking it up.
> 
> I've been able to confirm that Hello World works on micro:bit.
> And I could debug on micro:bit using gdb and pyocd.
> 
> I haven't done other things such as lighting of the LED.
> 
> Thanks
> Saito Yutaka
> 
> 
> 2020年7月3日(金) 23:42 Matias N. :
> 
> > Hi,
> > I can take a look and see if this would work on my nrf51822. Stil, it
> > would be better to have
> > the code author prepare a PR against NuttX. I see recent commits so it
> > appears an actively maintained
> > WIP.
> >
> > On a related subject: I have ordered an NRF52832 board and module, for
> > which my ultimate intentions would be to have NuttX support for RADIO
> > peripheral (as was discussed recently on the list). Since the board will
> > take some time to arrive and since it appears that NRF51822 RADIO
> > peripheral is mostly compatible, I could slowly start to work on it
> > (assuming this NRF51822 port is usable to do so).
> >
> > Again, I would learn Bluetooth low-level stuff on the way. I don't mind
> > this, but of course if someone else is working/planning to work on this it
> > would be good to align efforts to avoid duplicate and wasted work.
> >
> > Alan, if you haven't contacted the code author we could send him an email.
> >
> > Best,
> > Matias
> >
> > On Thu, Jul 2, 2020, at 19:43, Alan Carvalho de Assis wrote:
> > > Hi Everyone,
> > >
> > > It appears that someone is porting NuttX to BBC MicroBit board
> > >
> > > https://github.com/SaitoYutaka/incubator-nuttx
> > >
> > > Very interesting!
> > >
> > > He is testing on QEMU, maybe someone with an nRF51822 board could give
> > > it a try! ;-)
> > >
> > > BR,
> > >
> > > Alan
> > >
> >
> 

Scheduling work from a worker using the same work_s

[Anthony Merlino]

Hi,

I have a few spots in my code where I am doing something, and I'm just now
realizing I'm not explicitly sure if it's supported or not.

Here is my question:

Can work_queue be called from within a worker function that uses the same
work_s struct?

The documentation only says that if there is existing work, it will be
replaced. But what happens if there is existing work, AND it's currently
running?

I have a few areas where I'm doing it, and it does seem to be working, but
I'm not sure if there are any race conditions or other considerations that
I'm not aware of.

Best,
Anthony

Re: BBC MicroBit (nRF51822) running NuttX

[saito yutaka]

Hello.

Thanks for mail about my project.

I don't have much knowledge of the real time os, so I'm writing code while
looking it up.

I've been able to confirm that Hello World works on micro:bit.
And I could debug on micro:bit using gdb and pyocd.

I haven't done other things such as lighting of the LED.

Thanks
Saito Yutaka


2020年7月3日(金) 23:42 Matias N. :

> Hi,
> I can take a look and see if this would work on my nrf51822. Stil, it
> would be better to have
> the code author prepare a PR against NuttX. I see recent commits so it
> appears an actively maintained
> WIP.
>
> On a related subject: I have ordered an NRF52832 board and module, for
> which my ultimate intentions would be to have NuttX support for RADIO
> peripheral (as was discussed recently on the list). Since the board will
> take some time to arrive and since it appears that NRF51822 RADIO
> peripheral is mostly compatible, I could slowly start to work on it
> (assuming this NRF51822 port is usable to do so).
>
> Again, I would learn Bluetooth low-level stuff on the way. I don't mind
> this, but of course if someone else is working/planning to work on this it
> would be good to align efforts to avoid duplicate and wasted work.
>
> Alan, if you haven't contacted the code author we could send him an email.
>
> Best,
> Matias
>
> On Thu, Jul 2, 2020, at 19:43, Alan Carvalho de Assis wrote:
> > Hi Everyone,
> >
> > It appears that someone is porting NuttX to BBC MicroBit board
> >
> > https://github.com/SaitoYutaka/incubator-nuttx
> >
> > Very interesting!
> >
> > He is testing on QEMU, maybe someone with an nRF51822 board could give
> > it a try! ;-)
> >
> > BR,
> >
> > Alan
> >
>

Re: BBC MicroBit (nRF51822) running NuttX

[Matias N.]

Hi,
I can take a look and see if this would work on my nrf51822. Stil, it would be 
better to have
the code author prepare a PR against NuttX. I see recent commits so it appears 
an actively maintained
WIP.

On a related subject: I have ordered an NRF52832 board and module, for which my 
ultimate intentions would be to have NuttX support for RADIO peripheral (as was 
discussed recently on the list). Since the board will take some time to arrive 
and since it appears that NRF51822 RADIO peripheral is mostly compatible, I 
could slowly start to work on it (assuming this NRF51822 port is usable to do 
so).

Again, I would learn Bluetooth low-level stuff on the way. I don't mind this, 
but of course if someone else is working/planning to work on this it would be 
good to align efforts to avoid duplicate and wasted work.

Alan, if you haven't contacted the code author we could send him an email.

Best,
Matias 

On Thu, Jul 2, 2020, at 19:43, Alan Carvalho de Assis wrote:
> Hi Everyone,
> 
> It appears that someone is porting NuttX to BBC MicroBit board
> 
> https://github.com/SaitoYutaka/incubator-nuttx
> 
> Very interesting!
> 
> He is testing on QEMU, maybe someone with an nRF51822 board could give
> it a try! ;-)
> 
> BR,
> 
> Alan
> 

Re: Problem booting when using Nuttx on Qemu x86_64

[Yang Chung Fan]

Hi,

I have tested it on my machine.

Using commit deb3b13759fe08 , I can successfully boot into nsh.

For your reference, the following are my environments.

Build machine:
 - Windows10 WSL2 18.04
 - gcc (Ubuntu 9.3.0-11ubuntu0~18.04.1) 9.3.0

Execute machine:
 - Ubuntu 18.04
 - Xeon 2650 v4 / 16GB
 - Custom compiled kernel:
- Linux rtlab-linux 5.4.39-rt23+ #1 SMP PREEMPT_RT Mon May 11
22:10:55 JST 2020 x86_64 x86_64 x86_64 GNU/Linux
 - Custom compiled Qemu:
- QEMU emulator version 4.2.0 (v4.2.0-dirty)


BR,

--
Yang Chung Fan (楊宗凡) (ヤン　ゾン　ファン)

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Hi, Alan.

Thanks for the feedback.

Found out that I'm still get DEBUGASSERT(pholder != NULL) in function
nxsem_allocholder in file semaphore/sem_holder.c after
DEBUGASSERT(sem->semcount:

> Hi Oleg,
>
> I just responded your issue.
>
> I hope to have shed some light there.
>
> BR,
>
> Alan
>
> On 7/3/20, Oleg Evseev  wrote:
> > Regarding to can driver, from some moment I started getting
> > DEBUGASSERT(sem->semcount > in sem_post.c. Found the bug
> > https://github.com/apache/incubator-nuttx/issues/1354
> >
> > I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
> > the same bug or it is something else.
> >
> > --
> > With regards,
> > Oleg.
> >
> >
> > вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :
> >
> >> Find out that this happens while in poll.
> >>
> >> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
> >>
> >>> Hi all,
> >>>
> >>> I wonder how can I debug
> >>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
> >>> semaphore/sem_holder.c that happens after some time reading a lot of
> >>> messages from can bus in can_reciever task?
> >>>
> >>> Task  looks like this (CAN dev is opened as shared file with
> >>> file_open(&CANmodule->file, "/dev/can0", O_RDWR)):
> >>>
> >>> pollfd fds[1];
> >>> fds[0].fd = -1;
> >>> fds[0].ptr = CANmodule->file ;
> >>> fds[0].events = POLLIN | POLLFILE;
> >>>
> >>> while (!_thread_should_exit) {
> >>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
> >>>
> >>> if (fds[0].revents & POLLIN) {
> >>> /* Read the RX message */
> >>> CANreceive();
> >>> }
> >>> }
> >>>
> >>> void CANreceive(CANmodule_t *CANmodule){
> >>> struct can_msg_s msg = {};
> >>> ssize_t nbytes;
> >>>
> >>> nbytes = file_read(&CANmodule->file, &msg,  sizeof(struct
> can_msg_s)
> >>> );
> >>> ...
> >>> }
> >>>
> >>> Thanks in advance for any help.
> >>>
> >>> --
> >>> With regards,
> >>> Oleg.
> >>>
> >>
> >
>

Re: Problem booting when using Nuttx on Qemu x86_64

[Yang Chung Fan]

In addition, may I have your processor model please.

The Intel processors feature set varys quite a lot.

Maybe some feature settings are considered improper for your
processor, causing a GP.

BR,

-- 
Yang Chung Fan (楊宗凡) (ヤン　ゾン　ファン)

Re: Problem booting when using Nuttx on Qemu x86_64

[Yang Chung Fan]

Hi,

Good to hear more people trying our nuttx on x86_64.

> I am trying to run nuttx in a Qemu x86_64 VM but seem to be hitting some
> issue during early boot (as far as I can tell). I am using commit
> deb3b13759fe08 ("Udate TODO List") from yesterday.

That's quite new.
I was recently working with release 9.0 on a hypervisor called
jailhouse without issues.

I will try to take a look.

> Following the instructions for the board qemu-intel64, I configured and
> built the nuttx.elf using -
>
> ./tools/configure.sh qemu-intel64:nsh
> make

Although I ported x86_64 nuttx, I have zero experience with nsh port.
I only did the ostest.

But as you stated below, it doesn't seem like an application related
problem, but more architecture related..

> Seeing the output on the serial console, it feels like the cpu gets into
> a reboot loop with BIOS messages followed by grub loading the nuttx
> binary.
> ...
> Single stepping through the early startup code
> (arch/x86_64/src/intel64/intel64_head.S) suggests an unhandled exception
> is taken at the start of __nxstart. Considering the code has a comment
> indicating that it's executing from high memory, I am guessing an issue
> with the memory setup before getting here is causing an issue.

The processor has triple faulted and resets itself.
That's why it is looping.
I can think of a GP or a PF Fault happening during booting.

> I am using qemu[0] and gcc[1] shipped with Debian Bullseye (testing).

These shouldn't be an issue.

I have seen aliked looping problem during porting, mainly due to
improperly setup GPT causing GP or page table causing PF.

I suppose you didn't modify the code, therefore it seems strange to me.

BR,

-- 
Yang Chung Fan (楊宗凡) (ヤン　ゾン　ファン)

Re: How to debug DEBUGASSERT in shed?

[Alan Carvalho de Assis]

Hi Olev,

I just responded your issue.

I hope to have shed some light there.

BR,

Alan

On 7/3/20, Oleg Evseev  wrote:
> Regarding to can driver, from some moment I started getting
> DEBUGASSERT(sem->semcount in sem_post.c. Found the bug
> https://github.com/apache/incubator-nuttx/issues/1354
>
> I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
> the same bug or it is something else.
>
> --
> With regards,
> Oleg.
>
>
> вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :
>
>> Find out that this happens while in poll.
>>
>> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
>>
>>> Hi all,
>>>
>>> I wonder how can I debug
>>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
>>> semaphore/sem_holder.c that happens after some time reading a lot of
>>> messages from can bus in can_reciever task?
>>>
>>> Task  looks like this (CAN dev is opened as shared file with
>>> file_open(&CANmodule->file, "/dev/can0", O_RDWR)):
>>>
>>> pollfd fds[1];
>>> fds[0].fd = -1;
>>> fds[0].ptr = CANmodule->file ;
>>> fds[0].events = POLLIN | POLLFILE;
>>>
>>> while (!_thread_should_exit) {
>>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
>>>
>>> if (fds[0].revents & POLLIN) {
>>> /* Read the RX message */
>>> CANreceive();
>>> }
>>> }
>>>
>>> void CANreceive(CANmodule_t *CANmodule){
>>> struct can_msg_s msg = {};
>>> ssize_t nbytes;
>>>
>>> nbytes = file_read(&CANmodule->file, &msg,  sizeof(struct can_msg_s)
>>> );
>>> ...
>>> }
>>>
>>> Thanks in advance for any help.
>>>
>>> --
>>> With regards,
>>> Oleg.
>>>
>>
>

Re: How to debug DEBUGASSERT in shed?

[Oleg Evseev]

Regarding to can driver, from some moment I started getting
DEBUGASSERT(sem->semcounthttps://github.com/apache/incubator-nuttx/issues/1354

I don't know, was DEBUGASSERT(pholder != NULL) a different appearance of
the same bug or it is something else.

-- 
With regards,
Oleg.


вт, 30 июн. 2020 г. в 20:16, Oleg Evseev :

> Find out that this happens while in poll.
>
> вт, 30 июн. 2020 г. в 15:45, Oleg Evseev :
>
>> Hi all,
>>
>> I wonder how can I debug
>> DEBUGASSERT(pholder != NULL) in function nxsem_allocholder in file
>> semaphore/sem_holder.c that happens after some time reading a lot of
>> messages from can bus in can_reciever task?
>>
>> Task  looks like this (CAN dev is opened as shared file with
>> file_open(&CANmodule->file, "/dev/can0", O_RDWR)):
>>
>> pollfd fds[1];
>> fds[0].fd = -1;
>> fds[0].ptr = CANmodule->file ;
>> fds[0].events = POLLIN | POLLFILE;
>>
>> while (!_thread_should_exit) {
>> int ret = poll(fds, sizeof(fds) / sizeof(fds[0]), 1000);
>>
>> if (fds[0].revents & POLLIN) {
>> /* Read the RX message */
>> CANreceive();
>> }
>> }
>>
>> void CANreceive(CANmodule_t *CANmodule){
>> struct can_msg_s msg = {};
>> ssize_t nbytes;
>>
>> nbytes = file_read(&CANmodule->file, &msg,  sizeof(struct can_msg_s)
>> );
>> ...
>> }
>>
>> Thanks in advance for any help.
>>
>> --
>> With regards,
>> Oleg.
>>
>