Re: Working Effectively (was Point of Order)
On Wed, Jan 8, 2020 at 12:01 PM Gregory Nutt wrote: > > > >> Since code check part is available now, could I and Duo prepare to setup > >> Jenkins CI job firstly? > >> At fist, start to do the PR check stage according to the workflow option > >> chosen, then go to the build stage in the next couple of days. > >> We could optimize all the stages step by step once we start working > >> on it : > >> ) > > > > He should talk about how this would be implemented. > > > > In the past, we talk about trying to keep as much of the test support > > files out of the nuttx/ and apps/ repositories as possible. I would > > prefer that we try to keep those repositories as clean as possible > > with little or not testing files. > > Yes, all Jenkins related files should put on the Jenkins server as much as possible. > > We talking about a third testing/ repository that would be an > > environment for testing. In that repository, you could support the > > nuttx/ and apps/ directories as submodules and have an environment > > that could support unlimited testing without contaminating the nuttx/ > > and apps/ end-user directories. > > > > Can we please consider this? Let's not put any Jenkins CI in those > > end-user directories. > Let's see whether the submodule is needed during the development. But the principle is that: submodule should be used only for building/testing verification, the user/contributor don't need to know anything about submodule. > DavidS also suggested moving some of the common tools, such as nxstyle, > out of nuttx/tools to testing/tools. The coding standard check is not > specific to the nuttx/ repository. > But, most user also need these tools to ensure that they don't break the rule before submit PR. Basically, we have two catagory tools: 1.The workflow independent scripts, like checkpatch.sh and testbuild.sh These tools can run standalone in the developer machine, and very usefull for their daily work. The best location is nuttx/tools folder. 2.The workflow dependent scripts The best location for these tools is the Jenkins server. > Greg > >
Re: Jenkins CI
Now there is checkpatch.sh in nuttx/tools which call nxstyle to support patch/file/commit check. It could be used as a git pre-commit hook. Disruptive Solutions 于2020年1月8日周三 下午3:14写道： > Is there a “code style” formatter possible for say Eclipse for Apache > Nuttx? This can be custom made and gives the quality already while coding? > > Or is this not preferred adding it to a backend styling in git? > > Just thinking > Verstuurd vanaf mijn iPhone > > > Op 8 jan. 2020 om 05:03 heeft Gregory Nutt het > volgende geschreven: > > > > > >> > >>> Since code check part is available now, could I and Duo prepare to > setup > >>> Jenkins CI job firstly? > >> Where are you intending to set up this job? Here [1] or elsewhere? > > > > Hopefully not in the end-user directories :-\ > > > > Greg > > >
Re: Jenkins CI
If you prefer IDE(Eclipse) environment, here is instruction done by David: https://github.com/apache/incubator-nuttx/pull/12 Just need change "nxstyle -m 86" to "checkpatch.sh -f" On Wed, Jan 8, 2020 at 4:46 PM Haitao Liu wrote: > > Now there is checkpatch.sh in nuttx/tools which call nxstyle to support > patch/file/commit check. > It could be used as a git pre-commit hook. > > Disruptive Solutions 于2020年1月8日周三 > 下午3:14写道： > > > Is there a “code style” formatter possible for say Eclipse for Apache > > Nuttx? This can be custom made and gives the quality already while coding? > > > > Or is this not preferred adding it to a backend styling in git? > > > > Just thinking > > > > Verstuurd vanaf mijn iPhone > > > > > Op 8 jan. 2020 om 05:03 heeft Gregory Nutt het > > volgende geschreven: > > > > > > > > >> > > >>> Since code check part is available now, could I and Duo prepare to > > setup > > >>> Jenkins CI job firstly? > > >> Where are you intending to set up this job? Here [1] or elsewhere? > > > > > > Hopefully not in the end-user directories :-\ > > > > > > Greg > > > > >
RE: Working Effectively (was Point of Order)
Hi Xiang, -Original Message- From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] Sent: Tuesday, January 07, 2020 6:30 PM To: dev@nuttx.apache.org Subject: Re: Working Effectively (was Point of Order) David, why you think this tool promote the violation? [DBS] May be I do not understand what the -p and -c options do? "no new code" All lines in the file or the lines that were changed in the file? If it is the latter, then refer the this: o Strict conformance to the NuttX coding style. No "revolutionary" changes to the coding standard (but perhaps some "evolutionary" changes). o Personal or organizational preference is not a justification for a coding style change. o Nothing can come into NuttX that does not follow the coding standard. o Expediency is not a justification for violating the coding standard. With -p or -c option, we can ensure no new code violate the coding style. With -f option, we can review and correct the current code base. The jenkins job can select one option base on the workflow definition, the tool self hasn't any preference. Base on your measurement: https://github.com/apache/incubator-nuttx/pull/12 4043 files doesn't confirm the coding standard, how about each committer(candidate) take several folders to fix the style issue? [DBS] Yes when there is a documented set of work instructions (The commands and steps and repos to be used) David On Wed, Jan 8, 2020 at 12:40 AM David Sidrane wrote: > > +1 > > Adding a tool that promotes violating the INVIOLABLES.txt on several > aspect > (expedience and non conformant code into the repo) feels like a very bad > choice. > > How is this being justified? > > David > > > -Original Message- > From: Alin Jerpelea [mailto:jerpe...@gmail.com] > Sent: Tuesday, January 07, 2020 4:18 AM > To: dev@nuttx.apache.org > Subject: Re: Working Effectively (was Point of Order) > > I think that we should update all code with nxstyle then we start with a > clean code on which patches will be checked > > Alin > > On Tue, Dec 31, 2019 at 3:42 PM Haitao Liu wrote: > > > Greg, I'll finish the nxstyle & check script these days firstly and > > then > > take time to handle the two issues you mentioned if allowed. I wish I > > could > > be competent to take over full responsibility for nxstyle.c. > > > > Gregory Nutt 于2019年12月30日周一 下午11:31写道： > > > > > [moved from priv...@nuttx.apache.org] > > > > > > Hi, Xiao Xiang and Haitao Liu > > > > > > > Haitao is preparing a script for style check, the feature include: > > > > 1.Auto build nxstyle > > > > 2.Improve nxstyle to check the partial file for supporting patch > > > > like > > > file > > > > 3.Input can be the source files, patch file or commit id > > > > > > I mentioned that I had two things I planned to do for nxstyle.c too. > > > Perhaps Haitao would like to take on these changes too? > > > > > > 1. Derive maximum line width from block comments. Ref: > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#fileorganization > > > > > > * The Maximum line width should be the same as the width of the file > > > section block comment, by default the last asterisk '*' lies on > > > column 78, but wider lines are okay too, as long as things are > > > scaled corrected. Instead of the line width being a hardcoded 78 > > > or > > > specified the command line, nxstyle would parse the entire file, > > > look at the block comments, find the column of the last '*' The > > > line width is that colument + 1; > > > * Then also verify that every block comment in the file is the same > > width > > > * Perhaps the -m argument could change to a amount that you will > > > tolerate extending into the right margin. So the block comment > > > with > > > is 78, then -m 8 would allow lines to extend to 86. That is > > > better > > > than a hard-coded 86 because the line width will vary with file > > > content. For some register definition files, the line width may > > > be > > > 120 or so. In that case -m 8 would allow the line to extend to > > > 128. > > > > > > 2. Verify that file section block comments are present. > > > > > > * Add an enumeration value that indicates every block comment type. > > > See > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#cfilestructure > > > and > > > > > > > > https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#hfilestructure > > > * Currently logic detects only the presence of "* Private Functions" > > > and "* Private Functions". Add logic to detect all other the > > > block > > > comment types as well. > > > * Add a global variable to indicate which code block we are > > > currently > > > in. Each time a file section block comment is found, set the > > > global > > > variable. > > > * The if '# define" is encountered outside of the "* Pre-processor > > > Definitions" file section, emit an error
PR60 Needs Approval from Alin Jerpelea
Alin, you need to review this PR: https://github.com/apache/incubator-nuttx/pull/60 . I made a wild guess to get a clean compile but there is only a 50/50 chance that I guessed properly. Please check. This is holding up the build test now (we have not had a clean build test in over a week new). I tried to add you as a reviewer using your jerpelea github username, but github would not let me do that. You need to register your github username. It is not registered. See https://whimsy.apache.org/roster/ppmc/nuttx You need to do that on your account page: https://id.apache.org/?availid=jerpelea Greg
Re: Working Effectively (was Point of Order)
On Wed, Jan 8, 2020 at 3:05 AM Xiang Xiao wrote: > Yes, all Jenkins related files should put on the Jenkins server as > much as possible. What if something happens to the Jenkins server? Will the files exist somewhere else too? Thanks, Nathan
Re: Working Effectively (was Point of Order)
On Wed, Jan 8, 2020, 11:05 AM Nathan Hartman wrote: > On Wed, Jan 8, 2020 at 3:05 AM Xiang Xiao > wrote: > > > Yes, all Jenkins related files should put on the Jenkins server as > > much as possible. > > > What if something happens to the Jenkins server? Will the files exist > somewhere else too? > Also how are we going to test Mac and Windows using that build setup. This is one reason I asked about using GitHub Actions or something that easily provides that for us. >
Re: PR60 Needs Approval from Alin Jerpelea
I updated my details on my account and I will look at the issue ASAP Thanks Alin On Wed, Jan 8, 2020 at 8:05 PM Gregory Nutt wrote: > Alin, you need to review this PR: > https://github.com/apache/incubator-nuttx/pull/60 . I made a wild guess > to get a clean compile but there is only a 50/50 chance that I guessed > properly. Please check. This is holding up the build test now (we have > not had a clean build test in over a week new). > > I tried to add you as a reviewer using your jerpelea github username, > but github would not let me do that. > > You need to register your github username. It is not registered. See > https://whimsy.apache.org/roster/ppmc/nuttx > > You need to do that on your account page: > https://id.apache.org/?availid=jerpelea > > Greg > > >
RE: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
I just got a 23LC1024 (128kb SDRAM 1MBit) and want to "attach" this as external RAM. To scale up the free mem. I am looking at examples like stm32_extmem.c and qspi.. which one is best to use? And do I have to "make" a driver for it? And bind it to SPI? Or are my thoughts wrong? Thanks again...
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Hi Ben, AFAIK NuttX doesn't have support to Serial SRAM yet. At least I never see a driver to it. Normally people use real SDRAM chips controlled by FMSC (in the case of STM32). It should be a nice addition if you create a driver for Serial SRAM. BR, Alan On 1/8/20, disruptivesolution...@gmail.com wrote: > I just got a 23LC1024 (128kb SDRAM 1MBit) and want to "attach" this as > external RAM. To scale up the free mem. > > I am looking at examples like stm32_extmem.c and qspi.. which one is best > to > use? And do I have to "make" a driver for it? And bind it to SPI? Or are my > thoughts wrong? > > Thanks again... > >
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
AFAIK NuttX doesn't have support to Serial SRAM yet. At least I never see a driver to it. Normally people use real SDRAM chips controlled by FMSC (in the case of STM32). It should be a nice addition if you create a driver for Serial SRAM. You can't use serial SRAM from a framebuffer, however. If that is the intent. (It would have to be bigger as well). Serial SRAM cannot be randomly accessed like normal memory. QSPI is an option, perhaps, if you configure it to support random access. Regular FSMC SRAM on an STM32F4-Discovery daughterboard would be easier than either of those options.
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Oke I want it to extend the RAM just like FSMC does on the STM429i.. so in boot it has to expand and that the framebuffer can use it as if it already was there.. I will look into some examples where I can begin the 23LC1024 I will try first. Verstuurd vanaf mijn iPhone > Op 9 jan. 2020 om 00:23 heeft Alan Carvalho de Assis het > volgende geschreven: > > Hi Ben, > > AFAIK NuttX doesn't have support to Serial SRAM yet. > > At least I never see a driver to it. > > Normally people use real SDRAM chips controlled by FMSC (in the case of > STM32). > > It should be a nice addition if you create a driver for Serial SRAM. > > BR, > > Alan > >> On 1/8/20, disruptivesolution...@gmail.com >> wrote: >> I just got a 23LC1024 (128kb SDRAM 1MBit) and want to "attach" this as >> external RAM. To scale up the free mem. >> >> I am looking at examples like stm32_extmem.c and qspi.. which one is best >> to >> use? And do I have to "make" a driver for it? And bind it to SPI? Or are my >> thoughts wrong? >> >> Thanks again... >> >>
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
128Kb is still not big enough to allocate a 155Kb buffer. The memory has to be contiguous. Adding any chunk of memory < 155Kb will not give you more contiguous memory. The 23LC1024 is a serial, SPI SRAM you can't use a serial part for heap memory under any condition. You need to use a standard parallel memory interface as you would with any other SRAM. Don't waste your time with that. External SRAM normally connects via FSMC. For STM32F407, the STM324-EVAL is a good example: https://www.st.com/en/evaluation-tools/stm3240g-eval.html The STM324-EVAL uses a 16-Mbit SRAM, this one: http://www.issi.com/WW/pdf/61WV102416ALL.pdf. Schematics for the STM324-EVAL are here: https://www.st.com/resource/en/schematic_pack/stm324xg-eval_sch.zip Then you can look at the boards/arm/stm32/stm3240g-eval/src/stm32_boot.c: 79 #ifdef CONFIG_STM32_FSMC 80 /* If the FSMC is enabled, then enable SRAM access */ 81 82 stm32_selectsram(); 83 #endif And all of boards/arm/stm32/stm3240g-eval/src/stm32_selectsram.c QSPI is a possibility, I suppose. But you really should consider standard SRAM first. Greg I just got a 23LC1024 (128kb SDRAM 1MBit) and want to "attach" this as external RAM. To scale up the free mem. I am looking at examples like stm32_extmem.c and qspi.. which one is best to use? And do I have to "make" a driver for it? And bind it to SPI? Or are my thoughts wrong?
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Oke I want it to extend the RAM just like FSMC does on the STM429i.. so in boot it has to expand and that the framebuffer can use it as if it already was there.. I will look into some examples where I can begin the 23LC1024 I will try first. As Alan mentioned, the serial SRAM driver would be a welcome addition. However, you cannot use it to "To scale up the free memory." It does not support random access and cannot be used to increase the size of the heap you can allocate from. The STMF429i uses parallel, random access FSMC SRAM, not serial memory. That is how it is able to extend the free memory. SPI SRAM will not cut it.
Re: stm32_extmem.c and FSMC SDRAM solution in Nuttx?
Oke I want it to extend the RAM just like FSMC does on the STM429i.. so in boot it has to expand and that the framebuffer can use it as if it already was there.. I will look into some examples where I can begin the 23LC1024 I will try first. As Alan mentioned, the serial SRAM driver would be a welcome addition. However, you cannot use it to "To scale up the free memory." It does not support random access and cannot be used to increase the size of the heap you can allocate from. The STMF429i uses parallel, random access FSMC SRAM, not serial memory. That is how it is able to extend the free memory. SPI SRAM will not cut it. Backing up further... One thing that I never understood is why you need a framebuffer anyway. The STM32407 does not support the LTDC or DMA2D so you must be using a serial interface to the ILI LCD. Why do you need a framebuffer at all? For Littlevgl? Yes, Littevgl needs a framebuffer. NX does not. It can rend directly into the serial LCD GRAM. Performance of the serial LCD is not so great in that case unless you really crank up the SPI frequency and perform other optimizations.
Re: Jenkins CI
Hi, Justin, I have some questions about Apache Infra. Since NuttX would be built under Linux/Mac/Windows environment, does Apache Infra Jenkins CI provides Mac and Windows slave machines to ease CI build? Justin Mclean 于2020年1月8日周三 下午12:00写道： > Hi, > > Changing subjects. > > > Since code check part is available now, could I and Duo prepare to setup > > Jenkins CI job firstly? > > Where are you intending to set up this job? Here [1] or elsewhere? > > Thanks, > Justin > > 1. https://builds.apache.org >
Re: Jenkins CI
Hi, > I have some questions about Apache Infra. Since NuttX would be built under > Linux/Mac/Windows environment, does Apache Infra Jenkins CI provides Mac > and Windows slave machines to ease CI build? There was a mac machine, but I think it was removed a while back. There are windows machines (e.g [1]) and arm machines. I believe you can donate slaves to be added if you have large workload or require special setup. Thanks, Justin 1. https://builds.apache.org/job/netbeans-windows/
Re: Jenkins CI
Thanks, I think we can firstly get start in Linux and Windows. Then consider how to setup Mac later, donate slave or other. Two other question, nuttx uses some cross compile toolchains etc. In addition, Cygwin or MinGW is in need once nuttx built under Windows slaves. Should we ask for Apache Infra to help install in slave machines? Justin Mclean 于2020年1月9日周四 上午10:14写道： > Hi, > > > I have some questions about Apache Infra. Since NuttX would be built > under > > Linux/Mac/Windows environment, does Apache Infra Jenkins CI provides Mac > > and Windows slave machines to ease CI build? > > There was a mac machine, but I think it was removed a while back. There > are windows machines (e.g [1]) and arm machines. > > I believe you can donate slaves to be added if you have large workload or > require special setup. > > Thanks, > Justin > > 1. https://builds.apache.org/job/netbeans-windows/
Re: Jenkins CI
Hi, > Thanks, I think we can firstly get start in Linux and Windows. Then > consider how to setup Mac later, donate slave or other. > Two other question, nuttx uses some cross compile toolchains etc. In > addition, Cygwin or MinGW is in need once nuttx built under Windows slaves. > Should we ask for Apache Infra to help install in slave machines? If it's not already installed yet you need to ask for it to be installed. Best way to do is to raise an Infra JIRA. Thanks, Justin
Re: Jenkins CI
Ok, get it. Thanks! Justin Mclean 于2020年1月9日周四 上午11:07写道： > Hi, > > > Thanks, I think we can firstly get start in Linux and Windows. Then > > consider how to setup Mac later, donate slave or other. > > Two other question, nuttx uses some cross compile toolchains etc. In > > addition, Cygwin or MinGW is in need once nuttx built under Windows > slaves. > > Should we ask for Apache Infra to help install in slave machines? > > If it's not already installed yet you need to ask for it to be installed. > Best way to do is to raise an Infra JIRA. > > Thanks, > Justin
Re: Jenkins CI
Thanks, I think we can firstly get start in Linux and Windows. Then consider how to setup Mac later, donate slave or other. Two other question, nuttx uses some cross compile toolchains etc. In addition, Cygwin or MinGW is in need once nuttx built under Windows slaves. Should we ask for Apache Infra to help install in slave machines? MinGW is MSYS2, right? I use both Cygwin and MSYS2, they are a little different. There is usually a small number of people using some form of BSD, NetBSD or FreeBSD. Most macOS build issues are due to the fact that macOS uses the BSD coreutils which are not 100% compatible with GNU coreutils. I suspect you could substitute FreeBSD for macOS and also catch most if not all macOS build issues. In the past, there have been users on Solaris and HP-UX, but I don't think we need to go there now. Which targets do you plan to build? I routinely build all ARM targets (419 configurations and that omits several that are more difficult to automate), but we should also consider PIC32 and and Simulator. PIC32 would require a MIPS toolchain. There are many other architectures but most do not warrant investing a lot of test effort. Renesas RX65N, RISC-V, ESP32, AVR might be feasible because they also use GCC toolchains and do get used. Some of the others do not use GCC or have much less use. There have been IAR tools used with ARM in the past. There have been requests for Mikroelektronika tool support in the past, but that was never implemented. SDCC and ZiLOG tools are used for some architectures. I think we can ignore all those for now. Greg
Re: Jenkins CI
Haitao, Will the Jenkins CI scripts live in version control somewhere? cheers adam On Wed, Jan 8, 2020 at 7:44 PM Haitao Liu wrote: > Ok, get it. Thanks! > > Justin Mclean 于2020年1月9日周四 上午11:07写道： > > > Hi, > > > > > Thanks, I think we can firstly get start in Linux and Windows. Then > > > consider how to setup Mac later, donate slave or other. > > > Two other question, nuttx uses some cross compile toolchains etc. In > > > addition, Cygwin or MinGW is in need once nuttx built under Windows > > slaves. > > > Should we ask for Apache Infra to help install in slave machines? > > > > If it's not already installed yet you need to ask for it to be installed. > > Best way to do is to raise an Infra JIRA. > > > > Thanks, > > Justin > -- Adam Feuer
Re: Jenkins CI
On Wed, Jan 8, 2020 at 7:55 PM Gregory Nutt wrote: > I suspect you could substitute FreeBSD for macOS and also catch most if > not all macOS build issues. I think you could also require installing coreutils via brew or macports, they both have it. On macOS I can't imagine trying to build NuttX without having access to one of these package managers. cheers adam -- Adam Feuer a...@starcat.io
Question about savedefconfig warnings
Hi, I'm trying to save a defconfig, so I can put together an example for USB over Ethernet example I'm working on. It's working on the SAMA5D36-Xplained via USB 2.0 HS, by the way– very nice. When I do 'make savedefconfig' I get the following message twice: warning: (IMXRT_ENET && TIVA_PHY_INTERRUPTS && ARCH_BOARD_SAMA5D3X_EK && ARCH_BOARD_SAMA5D3_XPLAINED && ARCH_BOARD_SAMA5D4_EK && ARCH_BOARD_SAM4EEK && ARCH_BOARD_SAME70_XPLAINED && ARCH_BOARD_SAMV71_XULT && BOARD_CUSTOM_INTERRUPT) selects ARCH_PHY_INTERRUPT which has unmet direct dependencies (NETDEVICES && ARCH_HAVE_PHY) What's going on? How do I find out what's causing this and how do I make it go away? It's not causing a problem with the compile, that compiles and runs ok. cheers adam -- Adam Feuer
Re: Question about savedefconfig warnings
I forgot to attach the config file. Here it is. -adam On Wed, Jan 8, 2020 at 7:57 PM Adam Feuer wrote: > Hi, > > I'm trying to save a defconfig, so I can put together an example for USB > over Ethernet example I'm working on. It's working on the SAMA5D36-Xplained > via USB 2.0 HS, by the way– very nice. > > When I do 'make savedefconfig' I get the following message twice: > > warning: (IMXRT_ENET && TIVA_PHY_INTERRUPTS && ARCH_BOARD_SAMA5D3X_EK && > ARCH_BOARD_SAMA5D3_XPLAINED && ARCH_BOARD_SAMA5D4_EK && ARCH_BOARD_SAM4EEK > && ARCH_BOARD_SAME70_XPLAINED && ARCH_BOARD_SAMV71_XULT && > BOARD_CUSTOM_INTERRUPT) selects ARCH_PHY_INTERRUPT which has unmet direct > dependencies (NETDEVICES && ARCH_HAVE_PHY) > > What's going on? How do I find out what's causing this and how do I make > it go away? It's not causing a problem with the compile, that compiles and > runs ok. > > cheers > adam > -- > Adam Feuer > -- Adam Feuer
