RE: Stack overflow during system init.
Hi, I've been nearly completely out of order for the last week and a half, and I still have to fix #1900. Since your issue could be related: Is nxsig_initialize really causing a stack overflow in your case, or is it a false positive? Johannes > -Original Message- > From: Fotis Panagiotopoulos [mailto:f.j.pa...@gmail.com] > Sent: Tuesday, October 6, 2020 9:40 PM > To: dev@nuttx.apache.org > Subject: Stack overflow during system init. > > Hi everyone, > > I just enabled CONFIG_ARMV7M_STACKCHECK, as I would like to have this > functionality in my project, but I am facing problems. > > NuttX is not able to boot at all with this option selected. I stepped > through the code and it seems that nxsig_initialize actually causes a stack > overflow that is detected by the above check. > Is this a bug, or I should configure something in a different way? > > Then I realized that __stack_overflow_trap is broken. > When a stack overflow happens, this function is called which is supposed to > cause a hardfault. However as __stack_overflow_trap is a function itself, > __cyg_profile_func_enter is called again. Once again it detects the > overflow and calls __stack_overflow_trap, and so on... > > Finally, as I see, the stack check is performed while entering a function, > which is wrong. If there is a stack overflow, it will be detected at the > next function call, which may be at a irrelevant part of the code. I > believe that the check shall be performed on the exit of a function, in > which case you will be sure that this specific function caused the > overflow. And of course it will solve the issue above with > __stack_overflow_trap.
RE: Stack size alignment on arm
> So in px4, I end up seeing stack usage 100% on some threads (in "ps"), which > I want to fix. PR #1900 (https://github.com/apache/incubator-nuttx/pull/1900) fixes the issue. > In the past (9 or so years ago) there was an issue with floating point that > required the stack to be 8 byte aligned. It was too long ago, so I do not > remember the details This is currently not an issue. The alignment of the stack pointer to 8 bytes is assured. The size of the stack is not forced to be 8 aligned, but that doesn't matter: Either your stack is large enough, or not. But thanks for your hint. Johannes
RE: Stack size alignment on arm
> 1. Set the stack size as aligned already in > arch/arm/src/common/arm_createstack.c: > > - tcb->adj_stack_size = stack_size; > + tcb->adj_stack_size = STACK_ALIGN_DOWN(stack_size); > > 2. fix the do_stackcheck in a way that it doesn't start at (unaligned) > top, but at the first aligned stack address? > > 3. just leave nuttx as is, and go fix all the stack sizes in px4? > > > Initally I did the (1.) which seems to fix my problem. I had a look, and you're right. I've missed that arm_stack_color and do_check are now working differently concerning calculation of top (stackbase) address. If you don't mind (and since it is my mistake) I will provide a fix that weekend. Perhaps 32bit downalign instead of 32bit upalign the arm_stack_color stackbase would also be a solution as well, since TLS size is also 32bit aligned. This would keep the requested size in tcb->adj_stack_size. But I have to verify with arm_usestack.c Johannes
RE: Stack size alignment on arm
Is this happening on master as well? I've commited a change (#1562 ) to ARM stack management not long ago. Perhaps I missed something. I'll have a look. Johannes > I just encountered a problem with do_stackcheck(), and wanted to ask for > an opinion... > > In my (PX4) software I have got some threads, who define their stack > size unaligned by 4 bytes (uint32_t). The stack coloring works on > uint32, and thus doesn't color the topmost bytes of the stack when the > stack size is not aligned to 4. > > The arm_checkstack.c: do_stackcheck() on the other hand starts the > coloring check at " start = alloc & ~3;", which is actually (partially) > outside the stack. > > So in px4, I end up seeing stack usage 100% on some threads (in "ps"), > which I want to fix. So what would be the preferred way to fix this:
Kinetis QSPI MTD driver
Hello, I'd like to integrate a QSPI MTD driver for the MT25QU256 Nor Flash on Freedom-K28F board. Since the Kinetis QSPI module features memory mapping of the flash and XIP, it works using a lookup table, and therefore the driver will be very architecture specific. Where should I place the files? - Clock initialization into "board". - Common Kinetis-QSPI specific functions into "chip". So far so good. But where should I place the Flash specific MTD driver? Because of the Sequence LUT, it will only work with Kinetis (perhaps with i.MX RT, I think there are similarities). As it will look strange to have a mt25kinetis.c in "drivers/mtd", should I put it into "drivers/mtd", into "chip" or into "board"? Any suggestions? Regards, Johannes
RE: Query on USB Hub device node creation
> There will be no entry available in /dev directory for the USB Hub device. > > Is my understanding correct? > > Is this the expected behaviour of NuttX? I have no hardware around that weekend, so I can't verify. But as far as I can remember there's no node in /dev for a hub. Johannes
Re: LPWORK Queue and USB Host Serial
> -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Wednesday, August 26, 2020 3:34 PM > You must be using an STM32, right? The USB host on STM32 is garbage. No, I'm using a Kinetis K28 with EHCI, and I'm sure that problem is by design of the serial drivers: It's not a problem of bandwidth I'm encountering, it's just a problem of number of work queue threads. Both the CDC and the FT232R call DRVR_TRANSFER from a (virtual) endless loop inside the usbhost_rxdata_work function. That means they are most of the time waiting on a semaphore, but they block the work queue thread. So the workaround is increasing the number of LPWORK threads (as you mentioned). But at least for FT232R there's another problem: Since the usbhost_rxint function reschedules work regardless rx_datawork already running, I managed to eat up one work queue thread after the other by quick small reads from the fd. When rxint is called twice (disable/enable) during usbhost_rxdata_work waiting, you will have another thread blocked on a semaphore, and so on... So either we need an additional synch mechanism or we use dedicated threads. Long story short: I will file my PR for the FT232R driver in the next days. As soon as it is accepted I will rework the CDCACM as well. Johannes
LPWORK Queue and USB Host Serial
Hello, A short question concerning the use of LPWORK queue in FT232R and CDCACM USB Host drivers: Both block one LPWORK task per opened instance permanently. The FT232R rxdata_work USB transfer returns after each 16ms (USBHOST_FT232R_LATENCY) but since there are always at least two status bytes transferred it stays in the loop. (And the worse, if I'm correct, it can happen that there are way more than one LPWORK tasks blocked, because of race conditions.) The CDCACM rxdata_work USB transfer doesn't even return as long there are no bytes to transfer. At least with my connected Quectel EG25-G. I can't imagine that this is the correct use of a shared resource like work queues. For the FT232R I did a rework that uses a dedicated rxdata task (and because of "symmetry" a dedicated txdata task) per opened instance. Does it make sense to file a PR? If that one would be accepted I could rework the CDCACM driver accordingly. On a side note: I think PR #1624 is important (perhaps also for other EHCI Host drivers), because without it, the Asynchronus Schedule can get out of coherency in multi task accesses to EHCI. Johannes
NuttX Online Workshop
Just a hint: If I'm correct, https://nuttx.events/ is broken at the moment: There's no link to register for N.O.W. (or is registration closed?) and the countdown is only showing some html garbage. JOhannes
Re: USB host mass storage class automount.
> ... and shows a > profound lack of understanding of the OS architecture. > Thanks a lot, but what do you think why I'm asking questions? Would you please review PR #1531? I added a new USB mass storage class notifier. Johannes
Re: USB host mass storage class automount.
Would it be acceptable that the automount handler is called from usbhost_storage.c, from a modularity point of view? Because that way it would be only a notification towards the work queue, using a mechanism that is already in place. I don't like the idea to have another kthread that does only wait for a notification/event and then schedules itself the automount work on the queue. Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > > > But: I haven't yet found a way to determine if I enumerated really a mass > storage class device. So with only activating mass storage it seems rather > clean, but if I have multiple class drivers active, it gets complicated. > > Can you give a hint how to retrieve the type of driver bound to the > currently enumerated device? > That precise information is not available unless you add a notifier. > Bu you should be able to just use nx_stat() to see of the block driver > was created at /dev/sd* >
USB host mass storage class automount.
Hello, just a short question: I'd like to have my USB stick attached to USB high speed host automounted as vfat. Would it be acceptable to call mount/umount directly in the usbhost_storage.c where the blockdriver is registered/unregistered? For sure switchable with Kconfig options. I tried to setup a fs_automount instance, but I lack an IRQ/callback/connectionstate from host or msc I could use. Thanks, Johannes
Re: Some questions related PR#1478
As a conclusion for me: If you don't want to force braces, the macos/sim build test needs to be fixed. Importantly: It's not a style test that is failing, it's a build test. Nevertheless I will change the code in my PR to use braces, because it seems to be the preferred way (at least by Greg and Nathan). Regards, Johannes
Re: Some questions related PR#1478
Hmmm... I don't agree.
The Coding Standard encourages empty "while loops":
https://cwiki.apache.org/confluence/display/NUTTX/Coding+Standard#while
Why should this not applicable for "for loops"? I think there are many already
in the tree.
And why is only "Build / macOS (sim)" complaining?
Johannes
> -Original Message-
> From: Nathan Hartman [mailto:hartman.nat...@gmail.com]
> Sent: Friday, July 31, 2020 4:15 PM
> To: dev@nuttx.apache.org
> Subject: [!!Mass Mail]Re: Some questions related PR#1478
>
> On Fri, Jul 31, 2020 at 9:46 AM Schock, Johannes - NIVUS GmbH <
> johannes.sch...@nivus.com> wrote:
>
> > Hello,
> > I have two questions related PR#1478 (
> > https://github.com/apache/incubator-nuttx/pull/1478):
> >
> > 1. I think there's a configuration error with "Build / macOS (sim)" since
> > it is using -Wempty-body, or is this intentional?
> > It gives errors for
> > for (namelen = 0; dirinfo->fd_lfname[namelen] != '\0'; namelen++);
>
>
> That's asking for trouble...
>
> We should probably keep the warning and fix that code to read:
>
> for (.)
> {
> }
>
> Maybe even put a /* Do nothing */ comment in the body.
RE: Some questions related PR#1478
> From: Gregory Nutt [mailto:spudan...@gmail.com] > fsync on any open file descriptor will flush the file system since data > is only buffered for for metadata and one file at a time. This explains why my problem seems gone after I introduced a fsync on the file in my test case. I will have another look and will then reopen the PR, I think. Johannes
Some questions related PR#1478
Hello, I have two questions related PR#1478 (https://github.com/apache/incubator-nuttx/pull/1478): 1. I think there's a configuration error with "Build / macOS (sim)" since it is using -Wempty-body, or is this intentional? It gives errors for for (namelen = 0; dirinfo->fd_lfname[namelen] != '\0'; namelen++); 2. Is there a way to flush a fat file system? Because I think the unexpected behaviour I've seen was related to debugging and fat cache flush. I tried to use fsync on the folder (which was proposed in a linux related discussion), but open on a folder returns errno 21 (is a directory). Regards, Johannes
Re: RNDIS Kinetis
It seems sometimes reading the readme could save from heavy debugging and writing an email. But nevertheless, I filed a PR: https://github.com/apache/incubator-nuttx/pull/1456 RNDIS is working now, I have TCP/IP Telnet access through USB on Kinetis K28. Regards, Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Tuesday, July 21, 2020 3:53 PM > To: dev@nuttx.apache.org > Subject: [!!Mass Mail]Re: RNDIS Kinetis > > > > Now I'm facing a problem with the RNDIS driver under Kinetis USB device > (K28-Freedom), it is not working. > > If I'm not wrong I think I tracked it down: The Kinetis USB device driver > doesn't support accompanying data in an nonstandard OUT setup packet. > > Has someone already fixed this and can file a PR? If not I will try to fix > > it. > > That is a problem with several USB device drivers. There is more > description in the top-level TODO list: > > 1693 Title: EP0 OUT CLASS DATA > 1694 Description: There is no mechanism in place to handle EP0 OUT > data transfers. > 1695 There are two aspects to this problem, neither are > easy to fix > 1696 (only because of the number of drivers that would be > impacted): > 1697 > 1698 1. The class drivers only send EP0 write requests > and these are > 1699 only queued on EP0 IN by this drivers. There is > never a read > 1700 request queued on EP0 OUT. > 1701 2. But EP0 OUT data could be buffered in a buffer in > the driver > 1702 data structure. However, there is no method > currently > 1703 defined in the USB device interface to obtain the > EP0 data. > 1704 > 1705 Updates: (1) The USB device-to-class interface as > been extended so > 1706 that EP0 OUT data can accompany the SETUP request > sent to the > 1707 class drivers. (2) The logic in the STM32 F4 OTG FS > device driver > 1708 has been extended to provide this data. Updates are > still needed > 1709 to other drivers. > 1710 > 1711 Here is an overview of the required changes: > 1712 New two buffers in driver structure: > 1713 > 1714 1. The existing EP0 setup request buffer (ctrlreq, 8 > bytes) > 1715 2. A new EP0 data buffer to driver state structure > (ep0data, > 1716 max packetsize) > 1717 > 1718 Add a new state: > 1719 > 1720 3. Waiting for EP0 setup OUT data (EP0STATE_SETUP_OUT) > 1721 > 1722 General logic flow: > 1723 > 1724 1. When an EP0 SETUP packet is received: > 1725 - Read the request into EP0 setup request buffer > (ctrlreq, > 1726 8 bytes) > 1727 - If this is an OUT request with data length, set > the EP0 > 1728 state to EP0STATE_SETUP_OUT and wait to receive > data on > 1729 EP0. > 1730 - Otherwise, the SETUP request may be processed > now (or, > 1731 in the case of the F4 driver, at the conclusion > of the > 1732 SETUP phase). > 1733 2. When EP0 the EP0 OUT DATA packet is received: > 1734 - Verify state is EP0STATE_SETUP_OUT > 1735 - Read the request into the EP0 data buffer > (ep0data, max > 1736 packet size) > 1737 - Now process the previously buffered SETUP > request along > 1738 with the OUT data. > 1739 3. When the setup packet is dispatched to the class > driver, > 1740 the OUT data must be passed as the final > parameter in the > 1741 call. > 1742 > 1743 Update 2013-9-2: The new USB device-side driver for > the SAMA5D3 > 1744 correctly supports OUT SETUP data following the same > design as > 1745 per above. > 1746 > 1747 Update 2013-11-7: David Sidrane has fixed with issue > with the > 1748 STM32 F1 USB device driver. Still a few more to go > before this > 1749 can be closed out. > 1750 > 1751 Status: Open > 1752 Priority: High for class drivers that need EP0 data. For > example, the > 1753 CDC/ACM serial driver might need the line coding > data (that > 1754 data is not used currently, but it might be).
RNDIS Kinetis
Hello, I have again a little bit time to try out NuttX. Now I'm facing a problem with the RNDIS driver under Kinetis USB device (K28-Freedom), it is not working. If I'm not wrong I think I tracked it down: The Kinetis USB device driver doesn't support accompanying data in an nonstandard OUT setup packet. Has someone already fixed this and can file a PR? If not I will try to fix it. Regards, Johannes
RE: MSYS2 build slow
Sorry for being so unresponsive, we had bank holidays and I've been away from my computer for 3 days. > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Not if CONFIG_HOST_WINDOWS=y in the defconfig file. That is what is set > in stm32f4discovery:nsh: > > $ grep -r CONFIG_HOST > boards/arm/stm32/stm32f4discovery/configs/nsh/defconfig > CONFIG_HOST_WINDOWS=y With a virgin clone of apache/incubator-nuttx, configure outputs the following in MSYS2: $ tools/configure.sh stm32f4discovery/nsh Copy files Select CONFIG_HOST_LINUX=y Refreshing... time make -j real4m48,811s user0m41,836s sys 1m47,151s make clean -j time make -j real3m23,974s user0m33,409s sys 1m34,379s If I force -g this gives the following results: $ tools/configure.sh -g stm32f4discovery/nsh Copy files Select CONFIG_HOST_WINDOWS=y Select CONFIG_WINDOWS_MSYS=y Refreshing... real3m47,740s user0m37,817s sys 1m44,749s make clean -j time make -j real3m26,775s user0m29,002s sys 1m17,780s Overall I see some fluctuation (build time can be sometimes as well in the 7-8min range), but this seems to be related to my system. So for me there's one question left: Why seems Greg's CYGWIN to be faster than my MSYS2. But since I can again achieve build times in the 3 to 4min range, that's not of much importance. (Nevertheless I will try WSL someday.) Johannes
RE: MSYS2 build slow
Without specifying -g CONFIG_HOST_LINUX is assumed. This worked well in the past with MSYS2. But I will try -g later today. Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > > For MSYS2 on my i7-3770 it's (every tests with jobs enabled): > > # make distclean > > # tools/configure.sh stm32f4discovery/nsh > You really should specific -g on the configure.sh command line. > Otherwise, the system will assume you are building for Cygwin. There are > only a few differences between Cygwin and MSYS2, but though you should > know.
RE: MSYS2 build slow
For MSYS2 on my i7-3770 it's (every tests with jobs enabled): # make distclean # tools/configure.sh stm32f4discovery/nsh # time make -j real6m24,970s user1m5,615s sys 3m18,369s # make clean -j # time make -j real4m26,780s user0m58,376s sys 2m54,523s For comparison I checked out one commit before the "-I to INCDIR" change: #git checkout 23668a4b9b3c15c7367ff21befb4a6f48d01ffb7 # make distclean # tools/configure.sh stm32f4discovery/nsh # time make -j real3m52,370s user0m40,846s sys 2m1,092s # make clean -j # time make -j real3m0,449s user0m34,298s sys 1m39,438s What is interesting: With the change to incdir.c portions of the build process are still slower than before the "-I to INCDIR" change, but other portions are faster (libdrivers,libboard). It would be interesting if someone could verify my results (or am I the only MSYS2 user?). Overall it's still slower than before, but it's back in the ballpark. Thanks. Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Saturday, May 30, 2020 4:25 AM > To: dev@nuttx.apache.org > Subject: Re: MSYS2 build slow > > Johannes, > > PR 1149 has been merged. That means that the incdir.c program has now > been incorporated into the build system. It all checks out: I have > pretty thoroughly verified it on Cygwin and Abdelatif and Alan Carvalho > de Assis have checked it out well on Linux. The PR also passes all of > the PR build checks which verifies that it works correctly with Linux > and macOS. > > The only untested platform is MSYS and there could very well be issues > there. I have MSYS2 installed on two systems. I tried testing on my > laptop tonight but there is something screwed up in the MSYS2 > installation. I have both MSYS2 and Cygwin installed and I am thinking > that when I build with Cygwin , it messes up the MSYS2 configuration > (and vice versa). They share the same repository files. I am not sure > what is going on but I was not able to verify on MSYS2. I will try > again on my desktop in the morning. > > If you find problems, you can be pretty much assured that the problem is > in tools/incdir.c and I will work with you to resolve any issues that > you run across. If you do have problems, try using 'make V=1'. That > will show us the arguments to and the output from incdir.exe. > > Greg
RE: MSYS2 build slow
> From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com]
> Could you try the method I said before? Immediate make variable could
> avoid invoke the shell script at every reference location which is some form
> of cache inside make instead of incdir.sh.
It's
real22m50,526s
user1m37,024s
sys 4m25,220s
with
ARCHINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES := ${shell $(INCDIR) -s "$(CC)" $(TOPDIR)$(DELIM)include}
ARCHXXINCLUDES += ${shell $(INCDIR) -s "$(CC)"
$(TOPDIR)$(DELIM)include$(DELIM)cxx}
in nuttx/Make.defs.
So it's faster (23min < 36min) but still far away from 4-5min it used to be.
> From: Gregory Nutt [mailto:spudan...@gmail.com]
> Another, probably better solution, would be to re-write incdir.sh in C.
I must admit I thought about that idea also, but I wasn't sure about the
portability issue.
You could also think about a autogenerated Make.defs during configure with then
hard coded include paths which should be the fastest possibility.
Since Make.defs is already copied, perhaps it could also be modified on the fly.
Johannes
RE: MSYS2 build slow
By hardcoding os=Msys gcc=arm-none-eabi-gcc exefile=arm-none-eabi-gcc inside incdir.sh time tools/incdir.sh -s arm-none-eabi-gcc/home/Schock/nuttx/nuttx/include reduced from 180ms to 40ms. Overall, this reduced build time from 30min to an acceptable 6min. So incdir.sh is taking too much time in MSYS2 Isn't there a possibility to cache the results of the system checks inside incdir.sh? Regards, Johannes > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Friday, May 29, 2020 3:14 PM > To: dev@nuttx.apache.org > Subject: RE: MSYS2 build slow > > Would please someone do the following command on Linux and Cygwin? > > time tools/incdir.sh -s arm-none-eabi-gcc > /home/Schock/nuttx/nuttx/include > > (Replace the path with your NuttX path.) > > For MSYS2 it's in the range of: > > real0m0,189s > user0m0,061s > sys 0m0,045s > > Thanks, Johannes > > > From: Gregory Nutt [mailto:spudan...@gmail.com] > > Okay, so only MSYS2 is seeing a dramatic change. That is a mystery.
RE: MSYS2 build slow
Would please someone do the following command on Linux and Cygwin? time tools/incdir.sh -s arm-none-eabi-gcc /home/Schock/nuttx/nuttx/include (Replace the path with your NuttX path.) For MSYS2 it's in the range of: real0m0,189s user0m0,061s sys 0m0,045s Thanks, Johannes > From: Gregory Nutt [mailto:spudan...@gmail.com] > Okay, so only MSYS2 is seeing a dramatic change. That is a mystery.
RE: MSYS2 build slow
If I have done everything right with usage of git bisect, the below commit increased build time by factor 7 for MSYS2. Since this is a rather huge commit, I think I can't be helpful figuring out the actual reason. And I'm not sure if this is perhaps even considered acceptable. Regards, Johannes $ git bisect bad 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 is the first bad commit commit 7e5b0f81e93c7e879ce8434d57e8bf4e2319c1c0 Author: Xiang Xiao Date: Tue May 19 17:43:29 2020 +0800 build: Replace -I with INCDIR > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Wednesday, May 27, 2020 10:45 AM > To: dev@nuttx.apache.org > Subject: MSYS2 build slow > > Just as an intermediate result: > MSYS2 > > make distclean > tools/configure.sh stm32f4discovery/nsh > time make > > current master > real35m54,957s > user2m29,879s > sys 6m31,525s > > releases/9.0 > real4m39,324s > user0m28,553s > sys 1m23,113s > > The build is much slower than it used to be. > Does someone have an idea which commit could have caused this? > I will start a bisect later today. (Never did before, let's see.) > > Johannes
MSYS2 build slow
Just as an intermediate result: MSYS2 make distclean tools/configure.sh stm32f4discovery/nsh time make current master real35m54,957s user2m29,879s sys 6m31,525s releases/9.0 real4m39,324s user0m28,553s sys 1m23,113s The build is much slower than it used to be. Does someone have an idea which commit could have caused this? I will start a bisect later today. (Never did before, let's see.) Johannes
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
> From: Gregory Nutt [mailto:spudan...@gmail.com] > I just configured a new computer and I am having problems with MSYS2. I > can't even create the "symbolic" links needed at start up. I am not > sure why. Probably some priveleges issues. I activate Windows 10 Developer Mode, and create an environment variable named "MSYS" with value "winsymlinks:nativestrict". That's it. > But I did verify the build on Cygwin and it was about the same as > always. About 7 minutes using configuration stm32f4discovery with > realtime virus checking off. [That is disappointing to me because I > just built hot new Rizen 5 PC and expected better]. It's more than half an hour here with an (older) I7-3770. I will have a look today. Johannes
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
> -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Tuesday, May 26, 2020 4:20 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > > Today I had time to return to nuttx and rebased to master. > > But after doing a distclean and configuration, the build process on MSYS2 is > extremely slow. It takes hours for a build with "make -j8 V=1". > > I already had my company admin disable antivirus. Had there been a > change in the process? > > I use both MSYS2 and Cygwin (really both Cygwin) and have not noticed > any slowdown using Cygwin ... still minutes, certainly not hours. I > haven't used MSYS2 in some time. > > Perhaps you could do a git bisect and see if there is some particular > commit that introduced the MSYS2 problem > I'm currently updating MSYS2, and will then repeat the build. Then I'll test on another computer. And when it's happening there as well, I'll try to narrow down the reason.
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
Thanks a lot for the fixes. Yes I know that I won't have stdio in this configuration. I followed the README of stm32f429i-disco concerning CDC/ACM console, and it's for testing/playing anyway. Today I had time to return to nuttx and rebased to master. But after doing a distclean and configuration, the build process on MSYS2 is extremely slow. It takes hours for a build with "make -j8 V=1". I already had my company admin disable antivirus. Had there been a change in the process? Regards, Johannes > -Original Message- > From: Gregory Nutt [mailto:spudan...@gmail.com] > Sent: Saturday, May 23, 2020 5:02 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > > > PR #1105 should eliminate the primary cause of the error: fs_fdopen() > > will not longer set the errno variable. The secondary error, the > > uninitialized stack description, is still a problem. > Since the errno value was only set before fs_fdopen() failed, this means > that you system will still not work. It should not crash but it should > not work either. Now the fs_fdopen() calls will silently and > mysteriously fail, perhaps with the only symptom being no standard I/O > in the started tasks.
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
I implemented the change in nx_start.c with a quick and dirty extern const uintptr_t g_idle_topstack; just to see if it's working. It works. But since nx_start.c is not architecture specific and (according to the TODO) g_idle_topstack is not available in all architectures, this is no solution. > But many chipset forget to setup them for IDLE thread. If I understand correctly all(?) chipsets use nx_start, so the idle task tls seems to be never initialized. What about changing the call to nx_start(idle_stack_ptr, idle_stack_size)? Regards, Johannes > -Original Message- > From: Xiang Xiao [mailto:xiaoxiang781...@gmail.com] > Sent: Friday, May 22, 2020 1:51 PM > To: dev@nuttx.apache.org > Subject: Re: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED > not set > > The new implementation of set_errno require all thread(include IDLE) > initialize the stack related fields in tcb_s correctly. But many > chipset forget to setup them for IDLE thread. TODO contain an item > described this: > Task:IDLE THREAD TCB SETUP > Description: There are issues with setting IDLE thread stacks: > >1. One problem is stack-related data in the IDLE threads TCB. > A solution might be to standardize the use of > g_idle_topstack. > That you could add initialization like this in nx_start: > > @@ -344,6 +347,11 @@ void nx_start(void) > g_idleargv[1] = NULL; > g_idletcb.argv = g_idleargv; > > + /* Set the IDLE task stack size */ > + > + g_idletcb.cmn.adj_stack_size = > CONFIG_IDLETHREAD_STACKSIZE; > + g_idletcb.cmn.stack_alloc_ptr = (void > *)(g_idle_topstack - CONFIG_IDLETHREAD_STACKSIZE); > + > /* Then add the idle task's TCB to the head of > the ready to run list */ > > dq_addfirst((FAR dq_entry_t *)_idletcb, (FAR > dq_queue_t *)_readytorun); > > The g_idle_topstack variable is available for almost > all architectures: > > $ find . -name *.h | xargs grep g_idle_top > ./arm/src/common/up_internal.h:EXTERN const uint32_t > g_idle_topstack; > ./avr/src/avr/avr.h:extern uint16_t g_idle_topstack; > ./avr/src/avr32/avr32.h:extern uint32_t g_idle_topstack; > ./hc/src/common/up_internal.h:extern uint16_t > g_idle_topstack; > ./mips/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./misoc/src/lm32/lm32.h:extern uint32_t g_idle_topstack; > ./renesas/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > ./renesas/src/m16c/chip.h:extern uint32_t > g_idle_topstack; /* Start of the heap */ > ./risc-v/src/common/up_internal.h:EXTERN uint32_t > g_idle_topstack; > ./x86/src/common/up_internal.h:extern uint32_t > g_idle_topstack; > > That omits these architectures: sh1, sim, xtensa, z16, z80, > ez80, and z8. All would have to support this common > global variable. > > Also, the stack itself may be 8-, 16-, or 32-bits wide, > depending upon the architecture and do have differing > alignment requirements. > >2. Another problem is colorizing that stack to use with > stack usage monitoring logic. There is logic in some > start functions to do this in a function called go_nx_start. > It is available in these architectures: > > ./arm/src/efm32/efm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/kinetis/kinetis_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/sam34/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/samv7/sam_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32/stm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32f7/stm32_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/stm32l4/stm32l4_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/tms570/tms570_boot.c:static void > go_nx_start(void *pv, unsigned int nbytes) > ./arm/src/xmc4/xmc4_start.c:static void > go_nx_start(void *pv, unsigned int nbytes) > So, it become a block
RE: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
Another try with ".txt" extension. > -Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Friday, May 22, 2020 1:40 PM > To: 'dev@nuttx.apache.org' > Subject: Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not > set > > Hello, > I think there's a problem with set_errno() in nx_start(), when > CONFIG_TLS_ALIGNED is not set: > I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test > CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads > to a call of set_errno(). > But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board > goes into hardfault. > For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer > from arm_getsp() which accesses the stack pointer directly. > I think thread local storage for nx_start() should be handled differently, or > the stack_alloc_ptr should be set to a sane value. > I attach my config for reference, perhaps I'm missing something. > > Regards, Johannes > # # Automatically generated file; DO NOT EDIT. # Nuttx/x86_64 Configuration # # # Build Setup # # CONFIG_EXPERIMENTAL is not set # CONFIG_DEFAULT_SMALL is not set CONFIG_DEFAULT_TASK_STACKSIZE=4096 CONFIG_HOST_LINUX=y # CONFIG_HOST_MACOS is not set # CONFIG_HOST_WINDOWS is not set # CONFIG_HOST_OTHER is not set # # Build Configuration # CONFIG_APPS_DIR="../apps" CONFIG_BUILD_FLAT=y # CONFIG_BUILD_2PASS is not set # # Binary Output Formats # CONFIG_INTELHEX_BINARY=y # CONFIG_MOTOROLA_SREC is not set CONFIG_RAW_BINARY=y # CONFIG_UBOOT_UIMAGE is not set # CONFIG_DFU_BINARY is not set # # Customize Header Files # # CONFIG_ARCH_HAVE_STDINT_H is not set # CONFIG_ARCH_HAVE_STDBOOL_H is not set # CONFIG_ARCH_HAVE_MATH_H is not set # CONFIG_ARCH_FLOAT_H is not set CONFIG_ARCH_HAVE_STDARG_H=y # CONFIG_ARCH_STDARG_H is not set CONFIG_ARCH_HAVE_SETJMP=y # CONFIG_ARCH_SETJMP_H is not set # CONFIG_ARCH_DEBUG_H is not set # # Debug Options # CONFIG_DEBUG_ALERT=y CONFIG_DEBUG_FEATURES=y # # Debug SYSLOG Output Controls # # CONFIG_DEBUG_ERROR is not set # CONFIG_DEBUG_ASSERTIONS is not set # # Subsystem Debug Options # # CONFIG_DEBUG_BINFMT is not set # CONFIG_DEBUG_FS is not set # CONFIG_DEBUG_GRAPHICS is not set # CONFIG_DEBUG_LIB is not set # CONFIG_DEBUG_MM is not set # CONFIG_DEBUG_POWER is not set # CONFIG_DEBUG_SCHED is not set # # OS Function Debug Options # # CONFIG_DEBUG_IRQ is not set # # Driver Debug Options # # CONFIG_DEBUG_LEDS is not set # CONFIG_DEBUG_GPIO is not set # CONFIG_DEBUG_MEMCARD is not set # CONFIG_DEBUG_SPI is not set # CONFIG_DEBUG_TIMER is not set # CONFIG_DEBUG_USB is not set CONFIG_ARCH_HAVE_STACKCHECK=y # CONFIG_STACK_COLORATION is not set # CONFIG_ARCH_HAVE_HEAPCHECK is not set CONFIG_DEBUG_SYMBOLS=y CONFIG_ARCH_HAVE_CUSTOMOPT=y CONFIG_DEBUG_NOOPT=y # CONFIG_DEBUG_CUSTOMOPT is not set # CONFIG_DEBUG_FULLOPT is not set # # System Type # CONFIG_ARCH_ARM=y # CONFIG_ARCH_AVR is not set # CONFIG_ARCH_HC is not set # CONFIG_ARCH_MIPS is not set # CONFIG_ARCH_MISOC is not set # CONFIG_ARCH_RENESAS is not set # CONFIG_ARCH_RISCV is not set # CONFIG_ARCH_SIM is not set # CONFIG_ARCH_X86 is not set # CONFIG_ARCH_X86_64 is not set # CONFIG_ARCH_XTENSA is not set # CONFIG_ARCH_Z16 is not set # CONFIG_ARCH_Z80 is not set # CONFIG_ARCH_OR1K is not set CONFIG_ARCH="arm" # # ARM Options # # CONFIG_ARCH_CHIP_A1X is not set # CONFIG_ARCH_CHIP_AM335X is not set # CONFIG_ARCH_CHIP_C5471 is not set # CONFIG_ARCH_CHIP_DM320 is not set # CONFIG_ARCH_CHIP_EFM32 is not set # CONFIG_ARCH_CHIP_IMX1 is not set # CONFIG_ARCH_CHIP_IMX6 is not set # CONFIG_ARCH_CHIP_IMXRT is not set CONFIG_ARCH_CHIP_KINETIS=y # CONFIG_ARCH_CHIP_KL is not set # CONFIG_ARCH_CHIP_LC823450 is not set # CONFIG_ARCH_CHIP_LM is not set # CONFIG_ARCH_CHIP_LPC17XX_40XX is not set # CONFIG_ARCH_CHIP_LPC214X is not set # CONFIG_ARCH_CHIP_LPC2378 is not set # CONFIG_ARCH_CHIP_LPC31XX is not set # CONFIG_ARCH_CHIP_LPC43XX is not set # CONFIG_ARCH_CHIP_LPC54XX is not set # CONFIG_ARCH_CHIP_MAX326XX is not set # CONFIG_ARCH_CHIP_MOXART is not set # CONFIG_ARCH_CHIP_NRF52 is not set # CONFIG_ARCH_CHIP_NUC1XX is not set # CONFIG_ARCH_CHIP_S32K1XX is not set # CONFIG_ARCH_CHIP_SAMA5 is not set # CONFIG_ARCH_CHIP_SAMD2X is not set # CONFIG_ARCH_CHIP_SAML2X is not set # CONFIG_ARCH_CHIP_SAMD5X is not set # CONFIG_ARCH_CHIP_SAME5X is not set # CONFIG_ARCH_CHIP_SAM34 is not set # CONFIG_ARCH_CHIP_SAMV7 is not set # CONFIG_ARCH_CHIP_STM32 is not set # CONFIG_ARCH_CHIP_STM32F0 is not set # CONFIG_ARCH_CHIP_STM32L0 is not set # CONFIG_ARCH_CHIP_STM32G0 is not set # CONFIG_ARCH_CHIP_STM32F7 is not set # CONFIG_ARCH_CHIP_STM32H7 is not set # CONFIG_ARCH_CHIP_STM32L4 is not set # CONFIG_ARCH_CHIP_STR71X is not set # CONFIG_ARCH_CHIP_TMS570 is not set # CONFIG_ARCH_CHIP_TIVA is not set # CONFIG_ARCH_CHIP_XMC4 is not set #
Arm Kinetis: set_errno in nx_start with CONFIG_TLS_ALIGNED not set
Hello, I think there's a problem with set_errno() in nx_start(), when CONFIG_TLS_ALIGNED is not set: I disabled SERIAL_CONSOLE and DEV_CONSOLE, because I wanted to test CDCACM_CONSOLE. Now calling fs_fdopen() in group_setupstreams() leads to a call of set_errno(). But since tls_get_info() returns NULL pointer for stack_alloc_ptr the board goes into hardfault. For the CONFIG_TLS_ALIGNED case it would return the actual stack pointer from arm_getsp() which accesses the stack pointer directly. I think thread local storage for nx_start() should be handled differently, or the stack_alloc_ptr should be set to a sane value. I attach my config for reference, perhaps I'm missing something. Regards, Johannes
RE: Compilation paths
I can answer myself after doing some more general research: It's related to dereference of symbolic links when changing the working directory. As it can be seen in below message (objdump output), the working directory during compilation of the chip stuff is "arch/arm/src" which means the "chip" portion is part of the file path. But when the board stuff is compiled, the working directory is changed by entering "board", and this leads to a dereference of the symbolic link to the physical path as working directory. Please correct me if I'm wrong. Regards, Johannes > -----Original Message- > From: Schock, Johannes - NIVUS GmbH > [mailto:johannes.sch...@nivus.com] > Sent: Thursday, May 14, 2020 10:50 AM > To: dev@nuttx.apache.org > Subject: Compilation paths > > Hello, > Just a short question because of a lack of understanding: > During make process there are symlinks created: For an ARM target at least > "arch/arm/src/chip" and "arch/arm/src/board". > What I don't understand: > Why is the chip stuff compiled in the virtual folder, but the board stuff is > compiled in the physical folder. Wouldn't it make sense to also compile the > board specific code inside the virtual folder? > Because of this inconsistency(?) I always have problems with setting break > points in Eclipse, because I have to remember what the actual compile folder > really is. > Or is simply something wrong with my setup? > > As reference some objdump output of nuttx elf file: > > <977> DW_AT_name: (indirect string, offset: 0x400): > chip/kinetis_lowputc.c > <97b> DW_AT_comp_dir: (indirect string, offset: 0x1f): > C:\msys64\home\Schock\nuttx\nuttx\arch\arm\src > >DW_AT_name: (indirect string, offset: 0x76c2): > k28_bringup.c >DW_AT_comp_dir: (indirect string, offset: 0x12d9): > C:\msys64\home\schock\nuttx\nuttx\boards\arm\kinetis\freedom-k28f\src > > Regards, Johannes
Compilation paths
Hello, Just a short question because of a lack of understanding: During make process there are symlinks created: For an ARM target at least "arch/arm/src/chip" and "arch/arm/src/board". What I don't understand: Why is the chip stuff compiled in the virtual folder, but the board stuff is compiled in the physical folder. Wouldn't it make sense to also compile the board specific code inside the virtual folder? Because of this inconsistency(?) I always have problems with setting break points in Eclipse, because I have to remember what the actual compile folder really is. Or is simply something wrong with my setup? As reference some objdump output of nuttx elf file: <977> DW_AT_name: (indirect string, offset: 0x400): chip/kinetis_lowputc.c <97b> DW_AT_comp_dir: (indirect string, offset: 0x1f): C:\msys64\home\Schock\nuttx\nuttx\arch\arm\src DW_AT_name: (indirect string, offset: 0x76c2): k28_bringup.c DW_AT_comp_dir: (indirect string, offset: 0x12d9): C:\msys64\home\schock\nuttx\nuttx\boards\arm\kinetis\freedom-k28f\src Regards, Johannes
AW: Debugging Nuttx
If I recall correctly I created a folder named C:\mnt\ with a link (junction) to D:\ named "d" inside. (If the working disk of your IDE is D:\ try to put the junction into D:\mnt\) That allowed Eclipse to parse the file structure when I was testing Nuttx on Ubuntu Bash. Does this work with Visual Studio as well? I don't know. I'm not sure if the above is correct at all, I'm currently using MSYS2, which is slower, but usable. Johannes > -Ursprüngliche Nachricht- > Von: Eduard Niesner [mailto:niesneredu...@gmail.com] > Gesendet: Montag, 6. April 2020 23:33 > An: dev@nuttx.apache.org > Betreff: Re: Debugging Nuttx > > Here are the correct paths. The previous ones were a little bit confusing... > - Ubuntu Bash under Windows 10: > /mnt/d/Work/Development/Git/NuttxH7Ubuntu/Nuttx/arch/arm/src/chip/stm > 32_spi.c:635 > - Cygwin: > D:\Work\Development\Git\NuttxH7Cygwin\Nuttx\arch\arm\src/chip/stm32_sp > i.c:561 > > Edi > > On Tue, Apr 7, 2020 at 12:29 AM Eduard Niesner > wrote: > > > Thank you, Alexander! I will try your script in the next few days. > > > > I used objdump to generate the debug information for the libnuttx.a and > > libapps.a and this is how the paths from the debug information look like: > > > >- Ubuntu Bash under Windows 10: > > > /mnt/d/Work/Development/Git/NuttxH7Ubuntu/Nuttx/arch/arm/src/chip/stm > 32_spi.c:635 > >- Cygwin: > > > D:\Work\Development\Git\10NuttxCygwinForF7Upgrade7.26\Nuttx\arch\arm\ > src/chip/stm32_spi.c:561 > > > > Does anybody know if how I can setup Ubuntu Bash to generate the paths > > like Cygwin? > > > > > > > > On Mon, Apr 6, 2020 at 7:03 PM Alexander Oryshchenko < > > a.oryshche...@gmail.com> wrote: > > > >> Hi Eduard, > >> > >> Sure > >> > >> just go to nuttx directory and apply it: > >> git apply 0001-Replace-Linux-symlinks-with-junction-on-WSL.diff > >> > >> I do it right after clone/checkout of Nuttx source > >> > >> -Alexander > >> > >> On Mon, Apr 6, 2020 at 5:39 PM Eduard Niesner > > >> wrote: > >> > >>> Hi Alexander, > >>> > >>> Can you share your script and some instructions on how to use it? > >>> > >>> Thank you, > >>> Edi > >>> > >>> On Sun, Apr 5, 2020 at 11:19 PM Alexander Oryshchenko < > >>> a.oryshche...@gmail.com> wrote: > >>> > >>> > path -> patch, I lost characters sometimes :) > >>> > > >>> > вс, 5 апр. 2020 г., 23:17 Alexander Oryshchenko < > >>> a.oryshche...@gmail.com>: > >>> > > >>> > > Hi, > >>> > > > >>> > > For second your question I can little bit help you. I wrote path > >>> which > >>> > > replases "ln" command in link.sh with Windows links. Then both WLS > >>> and > >>> > > Windows understand it fine and you will not need to create directory > >>> and > >>> > > copy. But I have no idea about your first question. > >>> > > > >>> > > -Alexander > >>> > > > >>> > > вс, 5 апр. 2020 г., 23:12 Eduard Niesner : > >>> > > > >>> > >> Hi Alexander, > >>> > >> > >>> > >> I debug my application using Visual Studio and when I try to > >>> step-in a > >>> > >> function from Nuttx it looks for the source files in > >>> > >> C:\SysGCC\arm-eabi\mnt\d\work\NuttxH7\Nuttx\arch\arm\src\ > >>> > >> *chip\.c. *Since the "chip" folder is a simbolic link and > >>> is > >>> > not > >>> > >> accessible from Windows, Visual Studio cannot access it either. > >>> > >> > >>> > >> Since Visual Studio looks for the files in the "chip" folder, I > >>> need to > >>> > >> create it and copy the files from stm32H7 to it. This way, I am > >>> able to > >>> > >> debug my application and step in Nuttx functions as well. > >>> > >> I did not have the two issues from my initial email when I build > >>> Nuttx > >>> > >> with > >>> > >> Cygwin. I remember that the Nuttx/Apps repositories could not > >>> anywhere > >>> > on > >>> > >> my PC and also, the chip folder was always created after a > >>> successful > >>> > >> build > >>> > >> and its content was identical to the stm32H7 folder. So I did not > >>> have > >>> > to > >>> > >> do anything ... I was just doing a build and using the .a library > >>> in my > >>> > >> application and I was able to debug just fine. > >>> > >> > >>> > >> Also, I dont want to go back to Cygwin because in my experience, > >>> Cygwin > >>> > is > >>> > >> very slow compared to Ubuntu Bash. I am looking for a solution so > >>> that I > >>> > >> dont have do the two steps (copy Nuttx and Apps in the " > >>> > >> C:\SysGCC\arm-eabi\mnt\d" and copy stm32H7 content in chip > >>> folder.) > >>> > >> > >>> > >> Thank you, > >>> > >> Edi > >>> > >> > >>> > >> On Sun, Apr 5, 2020 at 9:46 AM Alexander Oryshchenko < > >>> > >> a.oryshche...@gmail.com> wrote: > >>> > >> > >>> > >> > Hello Eduard, > >>> > >> > > >>> > >> > Regarding you second question. > >>> > >> > arch/arm/source/chip and board are symbolic links. They are > >>> accessible > >>> > >> > under WSL (but at least for me inaccessible in Windows). But why > >>> do > >>> > you > >>> > >> > need to copy something here? > >>> > >> > > >>> > >> > -Alexander > >>> > >> > >
Re: nuttx-testing PR discussions on dev list
> -Ursprüngliche Nachricht- > Von: Abdelatif Guettouche [mailto:abdelatif.guettou...@gmail.com] > Gesendet: Sonntag, 22. März 2020 15:58 > An: dev@nuttx.apache.org > Betreff: Re: nuttx-testing PR discussions on dev list > > Hi, > Today I filled a JIRA issue to forward them to the commit list. > That's solved. They shouldn't appear in the dev list anymore. > Thank you.
nuttx-testing PR discussions on dev list
Sorry if I missed something. Is there a reason why nuttx-testing PR discussions on github are being forwarded to the dev list? I think either all PR discussions should be forwarded or none. I would prefer none. Regards, Johannes
Re: Should we relax precheck a little bit?
Part of the discussion on whitelisting for nxstyle went on on the Github PR: https://github.com/apache/incubator-nuttx/pull/569 To draw a conclusion from my side, I withdraw my supposal, because of "no metadata in source files". I will have a look at the .nxignore solution and if I find time I will file a PR. But this can happen the next weekend the earliest. So if one would like to take over this task earlier, please give notice. -Ursprüngliche Nachricht- Von: Gregory Nutt [mailto:spudan...@gmail.com] Gesendet: Sonntag, 15. März 2020 14:37 An: dev@nuttx.apache.org Betreff: Re: Should we relax precheck a little bit? > Yeah I thought about the too > > But think of the can of worm on the commit history: Every PR touches the cfg > file. I don't see that. Modifications to the white list file, whatever it is called, would be very rare. Only when a new non-compliant name is added which should be never. We should not permit people to create new non-compliant names. The existing non-compliant names are a consequence of names defined in other standards and by chip manufacturers. If POSIX changes or if we add support for new chips, then and only then would the whitelists change. I see no can. I see no worms.
Re: Should we relax precheck a little bit?
Hello, I filed a pull request that introduces an idea of controlling the behaviour of nxstyle from inside the file under test. https://github.com/apache/incubator-nuttx/pull/569 This would allow to address some special requirements that are needed in cornercases (e.g. whitelisting), and, by using the ignore feature, to switch of testing for ranges of the file that are correct but nxstyle isn't happy about it (yet unaddressed cornercases). This would give a contributor/commiter the possibility to explicitly pass the PR through the style check, and perhaps file an nxstyle issue. >From time to time we could grep for the ignore command and remove it if the >issue had been resolved. Please share your thoughts. Johannes P.S.: if some aren't happy with the xml-like syntax, we can change this for sure
Recent nxstyle changes
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
Just for reference another nand FTL, I found it some time ago, but never tried it: https://github.com/dlbeer/dhara Johannes
