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

2020-03-10 Thread Apache Jenkins Server
See 

Changes:


--
[...truncated 504.04 KB...]
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/configdata

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/sixlowpan

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...

mtd/at24xx.c:139:4: warning: #warning "Assuming MTD driver block size is the 
same as the FLASH page size" [-Wcpp]
 #  warning "Assuming MTD driver block size is the same as the FLASH page size"
^~~

Skipping: sim/cxxtest

Configuration/Tool: sim/nettest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Skipping: sim/nxwm

Configuration/Tool: sim/ipforward

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/nx

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/ostest

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/mount

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/minibasic

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/tcpblaster

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/touchscreen

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  Building NuttX...


Configuration/Tool: sim/bas

  Cleaning...
  Configuring...
  Copy files
  Select CONFIG_HOST_LINUX=y
  Refreshing...
  

NXFLAT Binary loader support for RX65N

2020-03-10 Thread Anjana
Hello Team,

I am trying to enable and test NXFLAT binary loader support for RX65N.

I have noticed that NXFLAT binary loader requires NXFLAT toolchain to be built 
using buildroot package.

The current NXFLAT toolchain supports ARM targets only. I have referred to 
https://cwiki.apache.org/confluence/display/NUTTX/NxFlat.

What I understand is, in order to support NXFLAT binary loader, the NXFLAT 
toolchain need to be built using the NuttX buildroot package from 
https://bitbucket.org/nuttx/buildroot/src/master/

Is there a way by which I can build NXFLAT toolchain for RX65N target?


Regards,

Anjana



Disclaimer: This email and any files transmitted with it are confidential and 
intended solely for the use of the individual or entity to whom they are 
addressed. If you are not the intended recipient of this message , or if this 
message has been addressed to you in error, please immediately alert the sender 
by reply email and then delete this message and any attachments. If you are not 
the intended recipient, you are hereby notified that any use, dissemination, 
copying, or storage of this message or its attachments is strictly prohibited. 
Email transmission cannot be guaranteed to be secure or error-free, as 
information could be intercepted, corrupted, lost, destroyed, arrive late or 
incomplete, or contain viruses. The sender, therefore, does not accept 
liability for any errors, omissions or contaminations in the contents of this 
message which might have occurred as a result of email transmission. If 
verification is required, please request for a hard-copy version.



Re: Re: Should we relax precheck a little bit?

2020-03-10 Thread Takashi Yamamoto
On Mon, Mar 9, 2020 at 6:09 AM Peter Van Der Perk
 wrote:
>
> Hi Adam,
>
> I've been trying to make a clang-format for NuttX however I did run in some 
> nasty bugs with clang-format.
> Mostly the inconsistent spacing caused by preprocessor directives (#ifdef) 
> etc.
> I've filed a bug on the LLVM bugtracker 
> (https://bugs.llvm.org/show_bug.cgi?id=44843) unfortunely I didn't get any 
> response.
> Please find below the clang-format I've used, I would say it's 80% done.
> But it's mostly that NXStyle requires special things that clang-format 
> doesn’t provide.

can you give me an example of special things?

>
> ---
> AccessModifierOffset: -6
> AlignAfterOpenBracket: Align
> AlignConsecutiveAssignments: 'true'
> AlignConsecutiveDeclarations: 'false'
> AlignEscapedNewlines: DontAlign
> AlignTrailingComments: 'true'
> AllowShortFunctionsOnASingleLine: None
> AllowShortIfStatementsOnASingleLine: 'false'
> AllowShortLoopsOnASingleLine: 'false'
> AlwaysBreakAfterDefinitionReturnType: None
> AlwaysBreakAfterReturnType: AllDefinitions
> BreakBeforeBinaryOperators: None
> BraceWrapping:
>   AfterCaseLabel:  true
>   AfterClass:  true
>   AfterControlStatement: true
>   AfterEnum:   true
>   AfterFunction:   true
>   AfterNamespace:  true
>   AfterObjCDeclaration: true
>   AfterStruct: true
>   AfterUnion:  true
>   BeforeCatch: true
>   BeforeElse:  true
>   IndentBraces:true
>   SplitEmptyFunction: true
>   SplitEmptyRecord: true
>   SplitEmptyNamespace: true
> BreakBeforeBraces: Custom
> ColumnLimit: 77
> CommentPragmas: '^ IWYU pragma:'
> ConstructorInitializerIndentWidth: '0'
> ContinuationIndentWidth: 2
> IncludeIsMainRegex: (Test)?$
> IndentPPDirectives: AfterHash
> IndentWidth: '2'
> JavaScriptQuotes: Leave
> MaxEmptyLinesToKeep: 2
> NamespaceIndentation: None
> ObjCBlockIndentWidth: '3'
> PenaltyBreakBeforeFirstCallParameter: '32'
> PenaltyBreakComment: 0
> PenaltyBreakFirstLessLess: '44'
> PenaltyBreakString: 838
> PenaltyExcessCharacter: '399916'
> PenaltyReturnTypeOnItsOwnLine: 30
> PointerAlignment: Right
> ReflowComments: 'true'
> SortIncludes: 'false'
> SpaceAfterCStyleCast: 'false'
> SpaceBeforeAssignmentOperators: 'true'
> SpaceBeforeParens: ControlStatements
> SpaceInEmptyParentheses: 'false'
> SpacesBeforeTrailingComments: 1
> SpacesInCStyleCastParentheses: 'false'
> SpacesInParentheses: 'false'
> SpacesInSquareBrackets: 'false'
> Standard: Cpp11
> TabWidth: '4'
> UseTab: Never
> ...
>
> > Thanks David. I'll try your approach. If there are some things that don't 
> > quite work with Clang-Format (I already found a few) I'll see about adding 
> > a fixup script pass at the end, or contributing some rules back to Clang.
> >
> > I'll try your idea about combining all the files under sched into a set.
> >
> > When you said you got 95% of the way there, do you have a .clang-format 
> > file that I could use as a starting point? If so that would help me start 
> > where you left off.
> >
> >cheers
> >adam


Re: Recent nxstyle changes

2020-03-10 Thread Gregory Nutt




I just like to discuss my recent nxstyle changes in regards to check the 
alignment of right of code comments according to coding standard.
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#comments

I checked against /sched before PR and everything looked good.
But know I see at least two PRs related to STM32H7 that show many new warnings 
in the style check because of the changes.
When running nxstyle against all files in arch/arm/src/stm32h7/hardware I get 
hundreds of warnings with
"warning: Wrong column position of comment right of code"
When looking at the contents of i.e. stm32_adc.h it doesn't look nice, but not 
so bad that one would expect 100+ warnings.

Currently I propagate the alignment requirements over # pre-processor lines 
without comment when not separated by blank lines, because they are still some 
kind of related block.
By not propagating over #define lines without comments I can reduce the 
warnings for above file to about 30, but nevertheless there are many.

What do you think?
1. Keep it as it is now.
2. Don't propagate over #define lines without comment.
3. Disable "Wrong column position"-warnings at all.

I think I would be fine with option 2.


I have ran nxstyle against hundreds of files since you made that 
change.  I have not seen any problems whatsoever.  So I suspect you are 
pushing a global decision based on the odd behavior of one file.  It 
could be that one right hand comment aligned error then propagates to 
many other similar, but invalid errors.  I think this one file is 
trigger the problem and you should get to root cause of the issue before 
you make any decisions.






Recent nxstyle changes

2020-03-10 Thread Schock, Johannes - NIVUS GmbH
I just like to discuss my recent nxstyle changes in regards to check the 
alignment of right of code comments according to coding standard.
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#comments

I checked against /sched before PR and everything looked good.
But know I see at least two PRs related to STM32H7 that show many new warnings 
in the style check because of the changes.
When running nxstyle against all files in arch/arm/src/stm32h7/hardware I get 
hundreds of warnings with
"warning: Wrong column position of comment right of code"
When looking at the contents of i.e. stm32_adc.h it doesn't look nice, but not 
so bad that one would expect 100+ warnings.

Currently I propagate the alignment requirements over # pre-processor lines 
without comment when not separated by blank lines, because they are still some 
kind of related block.
By not propagating over #define lines without comments I can reduce the 
warnings for above file to about 30, but nevertheless there are many.

What do you think?
1. Keep it as it is now.
2. Don't propagate over #define lines without comment.
3. Disable "Wrong column position"-warnings at all.

I think I would be fine with option 2.

Regards, Johannes


Re: let's discuss about the file system and nand flash driver

2020-03-10 Thread Schock, Johannes - NIVUS GmbH
Just for reference another nand FTL, I found it some time ago, but never tried 
it:

https://github.com/dlbeer/dhara

Johannes



Re: Github Issue on Build Failure

2020-03-10 Thread Xiang Xiao
On Wed, Mar 11, 2020 at 12:57 AM Anthony Merlino  wrote:
>
> I have been inactive for some time now, but I would like to get back up to
> speed and start making some contributions. One thing I was hoping to do was
> help get rid of some of the nightly build errors so that we can get a
> stable base and hopefully make a release soon. I spent the time getting the
> docker container set up and understanding how the current CI system works.
> Thanks to those who have been putting in the effort on this.
>
> I got the basics working and then looked to the nightly build log from last
> night so that I could try and replicate, then fix a bug. To my surprise,
> the build that failed last night built successfully. Of course a quick look
> at the recent commits shows that Xiang already fixed the issue.
>

The most build error inside the source code get fixed in recent month,
but two parallel build system issues happen randomly, that is why you
can pass the nightly build sometime especially if you run make with
small number of job. BTW, github precheck action seldom hit the
parallel build issue just because github's VM has two CPU core only
and we invoke make with -j2.

> This brings up a point that I saw mentioned in one of the email threads -
> we should use the Jenkins build failure to create an issue for us. This
> will allow us to see what progress is being made on each issue, and know if
> it has been resolved or not. Of course there is still a race condition
> where two people decide to pick up the same task at once, but this could be
> solved by the contributor assigning the issue to themselves, or commenting
> on it stating they are going to look into it.
>
> It looks like there is a Jenkins plugin that allows the Github issue to be
> created relatively easily. I'd be happy to try and get this working if
> everyone agrees.
>
> https://plugins.jenkins.io/github-issues/
>

It's a great addon to the nightly build system.

> Justin, could you please give me admin access to Jenkins?

All committers should already got the admin permission by default, you
can try login with your apache account here:
https://builds.apache.org
https://builds.apache.org/job/NuttX-Nightly-Build/

>
> Best,
> Anthony


Re: Github Issue on Build Failure

2020-03-10 Thread Xiang Xiao
On Wed, Mar 11, 2020 at 1:24 AM Gregory Nutt  wrote:
>
>
> >> It looks like there is a Jenkins plugin that allows the Github issue to be
> > created relatively easily. I'd be happy to try and get this working if
> > everyone agrees.
> Just as a matter of practicality, it would be good to restrict to build
> failures and not style check problems, at least for the time being.
> Maybe later we could add style issues.When we get license checking
> in place, the same would apply. We would also have to restrict this to
> files that exist, not to files being added.

Only github precheck action do the style check, the nightly build just
run full build test.


Re: let's discuss about the file system and nand flash driver

2020-03-10 Thread Xiang Xiao
On Tue, Mar 10, 2020 at 11:48 PM wangxinyu...@163.com
 wrote:
>
> hello
>
> I want to discuss about the nand flash and filesystem support.  I turned into 
> nuttx because
> I have a linux background and RTOS like freertos is most likely a bare OS 
> kernel ,porting
> exist things is annoying such as filesystem and POSIX interface etc.
> Some introduction of my situation and motivation:
> I'm trying to do porting the Nuttx onto the alientek apollo STM32F429 board.
> It's their website:
> http://www.alientek.com
> Their development board is very hot here in China, but it's a pity the 
> website is in Chinese Language only.
> I worked based onstm32f429i-disco and what I have done:
> a.uart
> b.external sdram
> c.led
> all works fine. Next step I want to get the Nand flash working with some 
> filesystem. Nand flash is Micron
> MT29F4G08.I realized that nuttx have no filesystem for nand on the shelf and 
> the exist filesystem have to
> do some changes to fit nand flash.I want a more mature filesystem which I can 
> think of from linux
> is something  based on mtd like jiffs2 or YAFFS2.Maybe ubifs is better but 
> It's not based on the mtd and more complex.

What's issue make you can't use SmartFS/LittleFS/SPIFFS directly on
MT29F4G08? From my experience, there isn't much difference between
NAND flash and NOR flash if the hardware can do ECC correction
automatically.

> I choosed YAFFS2 In fact the porting to Nuttx is pretty easy after I decided 
> to port YAFFS2 with its direct mode.
> Next step I  configured the FMC and got the FMC talk to nand correctly. Later 
> I choose to use the driver file
> mtd_nand.c later I find I have to implement the method in the nand_raw.h for 
> the lowest talking to nand in
> order to get all filesystem software stack working. I have a pause here and 
> looking forward to your advice
> for such topics:
> a. Could I benefit from Linux as I don't want to reinvent the wheel ? what 
> can I do to minium the effort ? Can we have a better sturcture?
> b. Should I put the raw_nand method drivers/mtd/ or the board specific 
> folder?I think I should put in the mtd folder for micron specific

Put it to arch/../src/... if it's specific for NAND controller on SoC,
or put it to drivers/mtd/ if it's specific to external NAND flash
vendor.

> c. license of YAFFS2 is GPL which would pollute the nuttx BSD license, what 
> is your advice? I have to link it with library format ?

GPL code can't upstream. It's fine to use it in your project, but you
need public all your source code per GPL requirement. If you don't
want to public your own code, nuttx/fs/userfs could help you to
isolate GPL code from BSD code.

> d. does someone have other working solutions for nand flash filesystem ?

SmartFS/LittleFS/SPIFFS/NXFFS is designed for the flash storage in
mind, all of them is bultin supported by NuttX, why not try they
first?

> e. As I understand, the raw nand filesystem is always a big headache for many 
> rtos, if you don't choose linux you only have very
> limited options for free use, FAT is a obvious option but you have to working 
> on the FTL level by yourself. It is meaningful to
> choose raw nand for low cost electronic product other than sd-card 
> competitable storgage.
>

> What's your opinion ?
>
>
>
> Best
>


Re: Github Issue on Build Failure

2020-03-10 Thread Gregory Nutt




It looks like there is a Jenkins plugin that allows the Github issue to be

created relatively easily. I'd be happy to try and get this working if
everyone agrees.
Just as a matter of practicality, it would be good to restrict to build 
failures and not style check problems, at least for the time being.  
Maybe later we could add style issues.    When we get license checking 
in place, the same would apply. We would also have to restrict this to 
files that exist, not to files being added.


RE: Github Issue on Build Failure

2020-03-10 Thread David Sidrane
> It looks like there is a Jenkins plugin that allows the Github issue to be
created relatively easily. I'd be happy to try and get this working if
everyone agrees.


+1
-Original Message-
From: Anthony Merlino [mailto:anth...@vergeaero.com]
Sent: Tuesday, March 10, 2020 9:57 AM
To: dev@nuttx.apache.org
Subject: Github Issue on Build Failure

I have been inactive for some time now, but I would like to get back up to
speed and start making some contributions. One thing I was hoping to do was
help get rid of some of the nightly build errors so that we can get a
stable base and hopefully make a release soon. I spent the time getting the
docker container set up and understanding how the current CI system works.
Thanks to those who have been putting in the effort on this.

I got the basics working and then looked to the nightly build log from last
night so that I could try and replicate, then fix a bug. To my surprise,
the build that failed last night built successfully. Of course a quick look
at the recent commits shows that Xiang already fixed the issue.

This brings up a point that I saw mentioned in one of the email threads -
we should use the Jenkins build failure to create an issue for us. This
will allow us to see what progress is being made on each issue, and know if
it has been resolved or not. Of course there is still a race condition
where two people decide to pick up the same task at once, but this could be
solved by the contributor assigning the issue to themselves, or commenting
on it stating they are going to look into it.

It looks like there is a Jenkins plugin that allows the Github issue to be
created relatively easily. I'd be happy to try and get this working if
everyone agrees.

https://plugins.jenkins.io/github-issues/

Justin, could you please give me admin access to Jenkins?

Best,
Anthony


Re: Github Issue on Build Failure

2020-03-10 Thread Gregory Nutt




I have been inactive for some time now, but I would like to get back up to
speed and start making some contributions.

I am really glad to see back!


Github Issue on Build Failure

2020-03-10 Thread Anthony Merlino
I have been inactive for some time now, but I would like to get back up to
speed and start making some contributions. One thing I was hoping to do was
help get rid of some of the nightly build errors so that we can get a
stable base and hopefully make a release soon. I spent the time getting the
docker container set up and understanding how the current CI system works.
Thanks to those who have been putting in the effort on this.

I got the basics working and then looked to the nightly build log from last
night so that I could try and replicate, then fix a bug. To my surprise,
the build that failed last night built successfully. Of course a quick look
at the recent commits shows that Xiang already fixed the issue.

This brings up a point that I saw mentioned in one of the email threads -
we should use the Jenkins build failure to create an issue for us. This
will allow us to see what progress is being made on each issue, and know if
it has been resolved or not. Of course there is still a race condition
where two people decide to pick up the same task at once, but this could be
solved by the contributor assigning the issue to themselves, or commenting
on it stating they are going to look into it.

It looks like there is a Jenkins plugin that allows the Github issue to be
created relatively easily. I'd be happy to try and get this working if
everyone agrees.

https://plugins.jenkins.io/github-issues/

Justin, could you please give me admin access to Jenkins?

Best,
Anthony


Re: Giant Board update

2020-03-10 Thread Gregory Nutt




I'll see if I can adapt the dramboot config for the SAMA5D27. I'll probably
have to set up SWD debugging... for that I need an adapter for my JLink,
and I'll need to solder some wires onto the GiantBoard SWD pads.

...

You might be able to use J-link with U-boot too.  Put a breakpoint at
0x20008040 and see what happens.

Try the above first.


Re: Giant Board update

2020-03-10 Thread Adam Feuer
Thanks Greg. You mentioned running from SDRAM before. I read the dramboot
section, now I understand this a little better.

My .config for the SAMA5D27-XULT has these two settings:

CONFIG_SAMA5_BOOT_SDRAM=y
CONFIG_BOOT_RUNFROM_SDRAM=y

So I think I am doing this already on the SAMA5D27-XULT, but it's using
U-Boot directly, not using the dramboot.

I'll see if I can adapt the dramboot config for the SAMA5D27. I'll probably
have to set up SWD debugging... for that I need an adapter for my JLink,
and I'll need to solder some wires onto the GiantBoard SWD pads.

cheers
adam

On Tue, Mar 10, 2020 at 9:23 AM Gregory Nutt  wrote:

>
> > ... I can fatload nuttx.bin. But when I run (go 0x20008040) nuttx
> > doesn't boot. Doing the same sequence on the SAMA5D2-XULT results in
> nuttx
> > booting...
>
> When I worked with the SAMA5D4-EK, I used a tiny bootloader that I wrote
> called dramboot.  It make debug a lot easier.  See
> boards/arm/sama5d4-ek/README.txt
>
> You might be able to use J-link with U-boot too.  Put a breakpoint at
> 0x20008040 and see what happens.
>
> NOTE:  I see that the Giant board in now in stock at Mouser US for $62.50
>
>

-- 
Adam Feuer 


Re: Giant Board update

2020-03-10 Thread Gregory Nutt




... I can fatload nuttx.bin. But when I run (go 0x20008040) nuttx
doesn't boot. Doing the same sequence on the SAMA5D2-XULT results in nuttx
booting...


When I worked with the SAMA5D4-EK, I used a tiny bootloader that I wrote 
called dramboot.  It make debug a lot easier.  See 
boards/arm/sama5d4-ek/README.txt


You might be able to use J-link with U-boot too.  Put a breakpoint at 
0x20008040 and see what happens.


NOTE:  I see that the Giant board in now in stock at Mouser US for $62.50



Re: let's discuss about the file system and nand flash driver

2020-03-10 Thread Adam Feuer
Hi,

NetBSD has a NAND flash file system (similar to JFFS2) that is BSD
Licensed:

https://en.wikipedia.org/wiki/CHFS
https://wiki.netbsd.org/tutorials/using_the_nand_emulator_and_chfs/
NetBSD CHFS source code on GitHub


Because of the license, might this be a better place to start?

(I found this on the Wikipedia List of Flash File Systems

.)

cheers
adam

On Tue, Mar 10, 2020 at 8:48 AM wangxinyu...@163.com 
wrote:

> hello
>
> I want to discuss about the nand flash and filesystem support.  I turned
> into nuttx because
> I have a linux background and RTOS like freertos is most likely a bare OS
> kernel ,porting
> exist things is annoying such as filesystem and POSIX interface etc.
> Some introduction of my situation and motivation:
> I'm trying to do porting the Nuttx onto the alientek apollo STM32F429
> board.
> It's their website:
> http://www.alientek.com
> Their development board is very hot here in China, but it's a pity the
> website is in Chinese Language only.
> I worked based onstm32f429i-disco and what I have done:
> a.uart
> b.external sdram
> c.led
> all works fine. Next step I want to get the Nand flash working with some
> filesystem. Nand flash is Micron
> MT29F4G08.I realized that nuttx have no filesystem for nand on the shelf
> and the exist filesystem have to
> do some changes to fit nand flash.I want a more mature filesystem which I
> can think of from linux
> is something  based on mtd like jiffs2 or YAFFS2.Maybe ubifs is better but
> It's not based on the mtd and more complex.
> I choosed YAFFS2 In fact the porting to Nuttx is pretty easy after I
> decided to port YAFFS2 with its direct mode.
> Next step I  configured the FMC and got the FMC talk to nand correctly.
> Later I choose to use the driver file
> mtd_nand.c later I find I have to implement the method in the nand_raw.h
> for the lowest talking to nand in
> order to get all filesystem software stack working. I have a pause here
> and looking forward to your advice
> for such topics:
> a. Could I benefit from Linux as I don't want to reinvent the wheel ? what
> can I do to minium the effort ? Can we have a better sturcture?
> b. Should I put the raw_nand method drivers/mtd/ or the board specific
> folder?I think I should put in the mtd folder for micron specific
> c. license of YAFFS2 is GPL which would pollute the nuttx BSD license,
> what is your advice? I have to link it with library format ?
> d. does someone have other working solutions for nand flash filesystem ?
> e. As I understand, the raw nand filesystem is always a big headache for
> many rtos, if you don't choose linux you only have very
> limited options for free use, FAT is a obvious option but you have to
> working on the FTL level by yourself. It is meaningful to
> choose raw nand for low cost electronic product other than sd-card
> competitable storgage.
>
> What's your opinion ?
>
>
>
> Best
>
>

-- 
Adam Feuer 


Re: let's discuss about the file system and nand flash driver

2020-03-10 Thread Gregory Nutt

b. Should I put the raw_nand method drivers/mtd/ or the board specific folder?I 
think I should put in the mtd folder for micron specific
That depends on if the code is modular and reusable by other 
architectures or it depends on the unique properties of the board. The 
better design would be to pat the driver in drivers/mtd and perhaps 
provide a "bottom half" driver interfaces in include/nuttx/mtd to handle 
board differences.

c. license of YAFFS2 is GPL which would pollute the nuttx BSD license, what is 
your advice? I have to link it with library format ?
No GPL code may come into NuttX.  That will never be possible  You are 
free to use YAFFS2 on your own, but it cannot come into NuttX.

e. As I understand, the raw nand filesystem is always a big headache for many 
rtos, if you don't choose linux you only have very
limited options for free use, FAT is a obvious option but you have to working 
on the FTL level by yourself. It is meaningful to
choose raw nand for low cost electronic product other than sd-card competitable 
storgage.


And alternative FTL layer would be a good solution.  The current one is 
very simple, it only creates a block driver.


You could create a NAND-specific FTL if you wanted.  The only issue with 
using NAND is that all FLASH file systems expect to able to change 1's 
to 0's at any time.  You can't do that with NAND because it breaks the 
ECC.  A more complex (and slower) FTL layer coude do this, however, by 
doing a SAVE - ERASE - MODIFY - RECALCULATE ECC - WRITE operation.


Greg





Giant Board update

2020-03-10 Thread Adam Feuer
I got my Giant Board yesterday and worked on it for about an hour last
night. I got the DBGU serial terminal working with U-Boot, and was able to
make an SDCard that will boot to the U-Boot that comes with the Giant
Board. I can fatload nuttx.bin. But when I run (go 0x20008040) nuttx
doesn't boot. Doing the same sequence on the SAMA5D2-XULT results in nuttx
booting...

The U-Boot version is different, so maybe the memory map is different? Or
maybe the way U-Boot sets uo the chip? It's using a device tree set up for
Linux. I also don't have an SWD debugger so can't debug right now.

That's where things stand. If anyone has any ideas on how to proceed I
would love to know them.

-adam
--
Adam Feuer 


let's discuss about the file system and nand flash driver

2020-03-10 Thread wangxinyu...@163.com
hello 

I want to discuss about the nand flash and filesystem support.  I turned into 
nuttx because 
I have a linux background and RTOS like freertos is most likely a bare OS 
kernel ,porting 
exist things is annoying such as filesystem and POSIX interface etc.  
Some introduction of my situation and motivation:
I'm trying to do porting the Nuttx onto the alientek apollo STM32F429 board.
It's their website:
http://www.alientek.com
Their development board is very hot here in China, but it's a pity the website 
is in Chinese Language only.
I worked based onstm32f429i-disco and what I have done:
a.uart 
b.external sdram
c.led
all works fine. Next step I want to get the Nand flash working with some 
filesystem. Nand flash is Micron 
MT29F4G08.I realized that nuttx have no filesystem for nand on the shelf and 
the exist filesystem have to
do some changes to fit nand flash.I want a more mature filesystem which I can 
think of from linux
is something  based on mtd like jiffs2 or YAFFS2.Maybe ubifs is better but It's 
not based on the mtd and more complex.
I choosed YAFFS2 In fact the porting to Nuttx is pretty easy after I decided to 
port YAFFS2 with its direct mode. 
Next step I  configured the FMC and got the FMC talk to nand correctly. Later I 
choose to use the driver file 
mtd_nand.c later I find I have to implement the method in the nand_raw.h for 
the lowest talking to nand in
order to get all filesystem software stack working. I have a pause here and 
looking forward to your advice 
for such topics:
a. Could I benefit from Linux as I don't want to reinvent the wheel ? what can 
I do to minium the effort ? Can we have a better sturcture?
b. Should I put the raw_nand method drivers/mtd/ or the board specific folder?I 
think I should put in the mtd folder for micron specific
c. license of YAFFS2 is GPL which would pollute the nuttx BSD license, what is 
your advice? I have to link it with library format ? 
d. does someone have other working solutions for nand flash filesystem ?
e. As I understand, the raw nand filesystem is always a big headache for many 
rtos, if you don't choose linux you only have very
limited options for free use, FAT is a obvious option but you have to working 
on the FTL level by yourself. It is meaningful to
choose raw nand for low cost electronic product other than sd-card competitable 
storgage. 

What's your opinion ?  



Best



How to get the rerefernce of buffer t....

2020-03-10 Thread Phani Kumar
Hello Greg and others,
I am developing a USB Host controller on NuttX with hardware which is not
compliant with OHCI or EHCI. As the hardware provides setup of hardware
registers for the USB Host, I am trying to "fit" it to OHCI spec (currently
using lpc17_40_usbhost as reference).
I am confused about the usage of following buffers and how to use them in
read/ write from hardware during interrupt (in bottom half).
During initialization, EDuffer, TDBuffer, TBBuffer and xferInfo buffers are
created. I am using chunk of memory for each of these and allocated 10
buffers for each (hardware has 10 endpoints) for ED, TD, TB and xferInfo. I
assume ED for Endpoint, TD for Transfer Descriptor, TB for TransferBuffer
and xferInfo is to manage the transfer details between interrupts.
With this setup and initial configuration, I am able to detect attaching of
device and then issue first setup packet. Device sends the data and
interrupt is triggered. I ack this interrupt and start the bottom half
(worker queue) to read the data (I have the data in the hardware registers)
and in bottom half, I am not sure, where should I read this data into - ED/
TD/ TB? Also I am not sure, how to get the reference to these buffers in
bottom half?
Some pointers/ direction would help me a lot.
Thanks in advance and with best regards,
Phani.

>


Re: [nuttx] How could I get all archived mail list history

2020-03-10 Thread Alan Carvalho de Assis
And the history of the yahoo groups is here:

https://nuttx.yahoogroups.narkive.com

On 3/10/20, Abdelatif Guettouche  wrote:
> Hi,
>
> The old google group has a search bar that you can use.
> https://groups.google.com/forum/#!forum/nuttx
> The Apache mailing list is archived and searchable, you can use this
> link: https://lists.apache.org/list.html?dev@nuttx.apache.org
> It defaults to the last month only, use the Advanced button to change that.
>
> All discussions have moved to the Apache list,
> d...@nuttx.incubator.apache.org, please use it in the future.
>
> On Tue, Mar 10, 2020 at 5:12 AM 2k4 w  wrote:
>>
>> Hello,
>>
>> I'm a beginner of the nuttx,before I started to ask someone I want an
>> efficiency way to determine whether the problem I met was solved or not.
>> As I know nuttx has google groups/yahoo groups/
>> d...@nuttx.incubator.apache.org , I have subscribe the google groups and
>> apache
>> mail list. I don't want to search the 3 place every time besides the mail
>> archive link in the apache server is not working,does anyone has
>> any advice?
>>
>> Best
>>
>> --
>> You received this message because you are subscribed to the Google Groups
>> "NuttX" group.
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to nuttx+unsubscr...@googlegroups.com.
>> To view this discussion on the web visit
>> https://groups.google.com/d/msgid/nuttx/73519d72-ac8f-452a-b6c4-96297c1c6b5e%40googlegroups.com.
>
> --
> You received this message because you are subscribed to the Google Groups
> "NuttX" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to nuttx+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/nuttx/CAN0SyTAUKAm3_OfBR9ZYeBHemwp6ex_amLiCJ5-4qv-C_VQ48A%40mail.gmail.com.
>


Re: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

2020-03-10 Thread Abdelatif Guettouche
Thanks Marcus and sorry for the inconvenience.
I created a PR based on your patch
(https://github.com/apache/incubator-nuttx/pull/520)

As Xiang noted, using Github puts the patch through the CI/CD checks.
If you can use Github please create PRs for future contributions.

Thanks.

On Tue, Mar 10, 2020 at 10:39 AM BERNET Markus
 wrote:
>
> Sorry about that, now with .txt extension
>
>
> -Original Message-
> From: Xiang Xiao 
> Sent: Dienstag, 10. März 2020 11:29
> To: dev@nuttx.apache.org
> Subject: Re: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE 
> definition
>
> This email is not from Hexagon’s Office 365 instance. Please be careful while 
> clicking links, opening attachments, or replying to this email.
>
>
> Or send PR to:
> https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-nuttx%2Fpullsdata=02%7C01%7C%7C8c627582846c461ed67708d7c4dddc37%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637194329483318246sdata=%2BNN8ppE13l7ue%2B8LAOyEiJ3w9SnwAaxFThuN0jUBCsQ%3Dreserved=0
> This is more interactive than email loop.
>
> On Tue, Mar 10, 2020 at 6:11 PM Abdelatif Guettouche 
>  wrote:
> >
> > Hi,
> >
> > Thanks for the patch, however the attachment didn't come through.
> > Could you please send it again with a .txt extension?
> >
> > Thanks.
> >
> > On Tue, Mar 10, 2020 at 9:59 AM BERNET Markus  
> > wrote:
> > >
> > > Hi all,
> > >
> > >
> > >
> > > I’ve found some typos in the SERIAL_CONSOLE definition, see attached 
> > > patch.
> > >
> > >
> > >
> > > Best regards,
> > >
> > > Markus
> > >
> > >
> > >
> > > Markus Bernet
> > > Senior Software Engineer
> > > T: +41 41 729 87 49
> > > E: markus.ber...@hexagon.com
> > >
> > > Hexagon Mining
> > > Baarerstrasse 133
> > > 6300 Zug, Switzerland
> > > hexagonmining.com | LinkedIn | Facebook | Twitter
> > >
> > >
> > >
> > >


RE: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

2020-03-10 Thread BERNET Markus
Sorry about that, now with .txt extension


-Original Message-
From: Xiang Xiao  
Sent: Dienstag, 10. März 2020 11:29
To: dev@nuttx.apache.org
Subject: Re: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE 
definition

This email is not from Hexagon’s Office 365 instance. Please be careful while 
clicking links, opening attachments, or replying to this email.


Or send PR to:
https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapache%2Fincubator-nuttx%2Fpullsdata=02%7C01%7C%7C8c627582846c461ed67708d7c4dddc37%7C1b16ab3eb8f64fe39f3e2db7fe549f6a%7C0%7C0%7C637194329483318246sdata=%2BNN8ppE13l7ue%2B8LAOyEiJ3w9SnwAaxFThuN0jUBCsQ%3Dreserved=0
This is more interactive than email loop.

On Tue, Mar 10, 2020 at 6:11 PM Abdelatif Guettouche 
 wrote:
>
> Hi,
>
> Thanks for the patch, however the attachment didn't come through.
> Could you please send it again with a .txt extension?
>
> Thanks.
>
> On Tue, Mar 10, 2020 at 9:59 AM BERNET Markus  
> wrote:
> >
> > Hi all,
> >
> >
> >
> > I’ve found some typos in the SERIAL_CONSOLE definition, see attached patch.
> >
> >
> >
> > Best regards,
> >
> > Markus
> >
> >
> >
> > Markus Bernet
> > Senior Software Engineer
> > T: +41 41 729 87 49
> > E: markus.ber...@hexagon.com
> >
> > Hexagon Mining
> > Baarerstrasse 133
> > 6300 Zug, Switzerland
> > hexagonmining.com | LinkedIn | Facebook | Twitter
> >
> >
> >
> >
From 354cb45fe21bc5cc70833ef313ea657884d16cc6 Mon Sep 17 00:00:00 2001
From: Markus Bernet 
Date: Fri, 6 Mar 2020 16:46:18 +0100
Subject: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

---
 arch/arm/src/stm32/stm32_uart.h   | 3 +--
 arch/arm/src/stm32f7/stm32_uart.h | 3 +--
 arch/arm/src/stm32h7/stm32_uart.h | 3 +--
 3 files changed, 3 insertions(+), 6 deletions(-)

diff --git a/arch/arm/src/stm32/stm32_uart.h b/arch/arm/src/stm32/stm32_uart.h
index 99e950c9a1..a4117c51a8 100644
--- a/arch/arm/src/stm32/stm32_uart.h
+++ b/arch/arm/src/stm32/stm32_uart.h
@@ -249,7 +249,6 @@
 #  undef CONFIG_UART4_SERIAL_CONSOLE
 #  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
-#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_UART8_SERIAL_CONSOLE
 #  define CONSOLE_UART 7
 #  define HAVE_CONSOLE 1
@@ -258,7 +257,7 @@
 #  undef CONFIG_USART2_SERIAL_CONSOLE
 #  undef CONFIG_USART3_SERIAL_CONSOLE
 #  undef CONFIG_UART4_SERIAL_CONSOLE
-#  undef CONFIG_UART6_SERIAL_CONSOLE
+#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
 #  undef CONFIG_UART7_SERIAL_CONSOLE
 #  define CONSOLE_UART 8
diff --git a/arch/arm/src/stm32f7/stm32_uart.h 
b/arch/arm/src/stm32f7/stm32_uart.h
index 9c326811d8..1ce0a7f212 100644
--- a/arch/arm/src/stm32f7/stm32_uart.h
+++ b/arch/arm/src/stm32f7/stm32_uart.h
@@ -156,7 +156,6 @@
 #  undef CONFIG_UART4_SERIAL_CONSOLE
 #  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
-#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_UART8_SERIAL_CONSOLE
 #  define CONSOLE_UART 7
 #  define HAVE_CONSOLE 1
@@ -165,7 +164,7 @@
 #  undef CONFIG_USART2_SERIAL_CONSOLE
 #  undef CONFIG_USART3_SERIAL_CONSOLE
 #  undef CONFIG_UART4_SERIAL_CONSOLE
-#  undef CONFIG_UART6_SERIAL_CONSOLE
+#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
 #  undef CONFIG_UART7_SERIAL_CONSOLE
 #  define CONSOLE_UART 8
diff --git a/arch/arm/src/stm32h7/stm32_uart.h 
b/arch/arm/src/stm32h7/stm32_uart.h
index bdd6bc9d81..c6cab46d5d 100644
--- a/arch/arm/src/stm32h7/stm32_uart.h
+++ b/arch/arm/src/stm32h7/stm32_uart.h
@@ -156,7 +156,6 @@
 #  undef CONFIG_UART4_SERIAL_CONSOLE
 #  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
-#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_UART8_SERIAL_CONSOLE
 #  define CONSOLE_UART 7
 #  define HAVE_CONSOLE 1
@@ -165,7 +164,7 @@
 #  undef CONFIG_USART2_SERIAL_CONSOLE
 #  undef CONFIG_USART3_SERIAL_CONSOLE
 #  undef CONFIG_UART4_SERIAL_CONSOLE
-#  undef CONFIG_UART6_SERIAL_CONSOLE
+#  undef CONFIG_UART5_SERIAL_CONSOLE
 #  undef CONFIG_USART6_SERIAL_CONSOLE
 #  undef CONFIG_UART7_SERIAL_CONSOLE
 #  define CONSOLE_UART 8
-- 
2.20.1.windows.1



Re: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

2020-03-10 Thread Xiang Xiao
Or send PR to:
https://github.com/apache/incubator-nuttx/pulls
This is more interactive than email loop.

On Tue, Mar 10, 2020 at 6:11 PM Abdelatif Guettouche
 wrote:
>
> Hi,
>
> Thanks for the patch, however the attachment didn't come through.
> Could you please send it again with a .txt extension?
>
> Thanks.
>
> On Tue, Mar 10, 2020 at 9:59 AM BERNET Markus  
> wrote:
> >
> > Hi all,
> >
> >
> >
> > I’ve found some typos in the SERIAL_CONSOLE definition, see attached patch.
> >
> >
> >
> > Best regards,
> >
> > Markus
> >
> >
> >
> > Markus Bernet
> > Senior Software Engineer
> > T: +41 41 729 87 49
> > E: markus.ber...@hexagon.com
> >
> > Hexagon Mining
> > Baarerstrasse 133
> > 6300 Zug, Switzerland
> > hexagonmining.com | LinkedIn | Facebook | Twitter
> >
> >
> >
> >


Re: [PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

2020-03-10 Thread Abdelatif Guettouche
Hi,

Thanks for the patch, however the attachment didn't come through.
Could you please send it again with a .txt extension?

Thanks.

On Tue, Mar 10, 2020 at 9:59 AM BERNET Markus  wrote:
>
> Hi all,
>
>
>
> I’ve found some typos in the SERIAL_CONSOLE definition, see attached patch.
>
>
>
> Best regards,
>
> Markus
>
>
>
> Markus Bernet
> Senior Software Engineer
> T: +41 41 729 87 49
> E: markus.ber...@hexagon.com
>
> Hexagon Mining
> Baarerstrasse 133
> 6300 Zug, Switzerland
> hexagonmining.com | LinkedIn | Facebook | Twitter
>
>
>
>


[PATCH] stm32/stm32f7/stm32h7: Fix bugs in SERIAL_CONSOLE definition

2020-03-10 Thread BERNET Markus
Hi all,

I've found some typos in the SERIAL_CONSOLE definition, see attached patch.

Best regards,
Markus

Markus Bernet
Senior Software Engineer
T: +41 41 729 87 49
E: markus.ber...@hexagon.com
Hexagon Mining
Baarerstrasse 133
6300 Zug, Switzerland
hexagonmining.com | 
LinkedIn | 
Facebook
 | 
Twitter




Re: Should we relax precheck a little bit?

2020-03-10 Thread Xiang Xiao
On Tue, Mar 10, 2020 at 1:17 AM Gregory Nutt  wrote:
>
>
> > - Fixing the entire file we touch helps makes things better overall even
> > though its painful in the short run.
> > - Having a tool that produces accurate style recommendations is very
> > important— it's hard to know what to fix and what not to fix if the tool
> > doesn't give accurate messages.
>
> I don't know how long it will take, but these two things converging is
> the keep to ending the pain permanently:  Fixing non-compliant files and
> improving the tools.
>
> I think we should at least wait a little while.  If it takes too long
> and does not converge to a reasonable solution in the near future, we
> can revisit this.

Ok, let's wait for sometime to see the result. Since the workflow
isn't lockdown yet, but the precheck is running for each PR now, I
would suggest that PR must pass the precheck before merging to ensure
the basic quality.

>
> > - Making the tool only look at the differences seems complicated and not
> > what we want in the long run.
>
> nxstyle does already support this option:
>
> $ tools/nxstyle.exe -h
> nxstyle version 0.01
>
> Usage:  nxstyle [-m ] [-v ] [-r ] 
>  nxstyle -h this help
>  nxstyle -v  where level is
> 0 - no output
> 1 - PASS/FAIL
> 2 - output each line (default)
>
> The -r option specifies a range of line numbers to test.
>
> So it is not complicated for nxstyle (CI logic would need some
> extension, however).  The real question is whether we should do that
> rather than if it is difficult to do.
>

CI logic is also ready now, we just need pass -r to checkpatch.sh
which will generate the list of start/count for nxstyle to just cover
the modified lines.

>
>