userspace/kernel isolation question

[Takashi Yamamoto]

hi,

while looking at PROTECTED build,
i noticed that it was trivial for userspace code to bypass the
protection and access kernel memory.
eg. by passing kernel pointer to system calls.
and it seems that it isn't the only way for userspace to trick the kernel.

are these by design? eg. not a problem for what nuttx is intended for.
or bug/overlook/todo/nice-to-have?

background: i'm familiar with "full-sized" operating systems like bsd.
but i'm new to nuttx.

Re: Build problems with ZDS-II

[Gregory Nutt]

I saw several patch for z80, does the problem get fixed or we need take a look?

No, it is not fixed.  That is just repartitioning of functionality.

Re: Build problems with ZDS-II

[Xiang Xiao]

Greg,
I saw several patch for z80, does the problem get fixed or we need take a look?

Thanks
Xiang

On Fri, Feb 21, 2020 at 4:25 AM Gregory Nutt  wrote:
>
> Here is a little more detail about the error:
> >
> >   Here are the problems that I see now:
> >
> > 1. The eZ80 COMPILE target generates the .obj file without using the
> > fully decorated object name.  For example, when it is supposed to
> > generate:
> >
> > 
> > mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> >
> > It instead generates:
> >
> > mkfatfs.obj
> >
> > That should be easy to fix in the COMPILE and ASSEMBLE definitions.
> >
> > 2. The full path to the archive is
> >
> > D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib
> >
> > But by the time it gets to the ZDS-II librarian, it becomes:
> >
> > D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib
> >
> > I haven't figures out where the backslashes are being lost yet.
> >
> > I am expecting that this explicit GCC command option will cause
> > failures too:
> >
> > ./Makefile: $(call COMPILE, -fno-lto $<, $@)
> >
> > That really should be dependent on CONFIG_ARCH_TOOLCHAIN_GNU. There
> > should be an issue opened up on that.
> >
> > These all seem like simple things, but I haven't solved them all yet.
> > Makefiles are too difficult to debug!
> >
> Detailed output with V=1 and some instrumentation:
>
> make[2]: Entering directory
> 
> '/cygdrive/d/Spuda/Documents/projects/nuttx/master/apps-fork/fsutils/mkfatfs'
>
> ### Here three files are compiled.  They still generate the
> undecorated object files.
>
> /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
> -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
> -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
> -NOigcase
> 
> -include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -warn -nodebug -NOsdiopt"
> 
> -stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -usrinc:'.' -define:_EZ80F91 -define:
> -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
> `cygpath -w " mkfatfs.c"`
> mkfatfs.c
>
> /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
> -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
> -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
> -NOigcase
> 
> -include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -warn -nodebug -NOsdiopt"
> 
> -stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -usrinc:'.' -define:_EZ80F91 -define:
> -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
> `cygpath -w " configfat.c"`
> configfat.c
>
> /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
> -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
> -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
> -NOigcase
> 
> -include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -warn -nodebug -NOsdiopt"
> 
> -stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
> -usrinc:'.' -define:_EZ80F91 -define:
> -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
> `cygpath -w " writefat.c"`
> writefat.c
>
> ### Here is the ARCHIVE.  A debug echo shows that $1, $2m, and $AR
> are okay
>
> 1= D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib
> 2=
> 
> mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> 
> configfat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> 
> writefat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> AR=/cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80lib.exe
>
> ### This is the ARCHIVE loop.  Things are divided on separate lines
> to make it more readable
>
> for __obj in
> 
> mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> 
> configfat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> 
> writefat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
> ; \
> do \
> 

Re: [PATCH] Fix printed "|| { ar blablabla FAILED!" after $(Q) removed

[Gregory Nutt]

Please apply attached patch to remove annoying "FAILED!" message.


Committed.  Also, since the echo was removed and since $(Q) was only 
removed so that you could see the echo output, I restored the $(Q)


You change to tools/Config.mk made the normal and Windows native case 
identical.


Greg

Podling Nuttx Report Reminder - March 2020

[jmclean]

Dear podling,

This email was sent by an automated system on behalf of the Apache
Incubator PMC. It is an initial reminder to give you plenty of time to
prepare your quarterly board report.

The board meeting is scheduled for Wed, 18 March 2020, 10:30 am PDT.
The report for your podling will form a part of the Incubator PMC
report. The Incubator PMC requires your report to be submitted 2 weeks
before the board meeting, to allow sufficient time for review and
submission (Wed, March 04).

Please submit your report with sufficient time to allow the Incubator
PMC, and subsequently board members to review and digest. Again, the
very latest you should submit your report is 2 weeks prior to the board
meeting.

Candidate names should not be made public before people are actually
elected, so please do not include the names of potential committers or
PPMC members in your report.

Thanks,

The Apache Incubator PMC

Submitting your Report

--

Your report should contain the following:

*   Your project name
*   A brief description of your project, which assumes no knowledge of
the project or necessarily of its field
*   A list of the three most important issues to address in the move
towards graduation.
*   Any issues that the Incubator PMC or ASF Board might wish/need to be
aware of
*   How has the community developed since the last report
*   How has the project developed since the last report.
*   How does the podling rate their own maturity.

This should be appended to the Incubator Wiki page at:

https://cwiki.apache.org/confluence/display/INCUBATOR/March2020

Note: This is manually populated. You may need to wait a little before
this page is created from a template.

Note: The format of the report has changed to use markdown.

Mentors
---

Mentors should review reports for their project(s) and sign them off on
the Incubator wiki page. Signing off reports shows that you are
following the project - projects that are not signed may raise alarms
for the Incubator PMC.

Incubator PMC

[PATCH] Fix printed "|| { ar blablabla FAILED!" after $(Q) removed

[Alan Carvalho de Assis]

Please apply attached patch to remove annoying "FAILED!" message.

BR,

Alan
From 4827ab2494de4e8743ffcfd030c423ee9c40218c Mon Sep 17 00:00:00 2001
From: Alan Carvalho de Assis 
Date: Thu, 20 Feb 2020 21:15:50 -0300
Subject: [PATCH] Fix printed "|| { ar blablabla FAILED!" after $(Q) removed

---
 boards/z16/z16f/z16f2800100zcog/scripts/Make.defs | 2 +-
 boards/z80/ez80/ez80f910200kitg/scripts/Make.defs | 2 +-
 boards/z80/ez80/ez80f910200zco/scripts/Make.defs  | 2 +-
 boards/z80/ez80/makerlisp/scripts/Make.defs   | 2 +-
 boards/z80/z8/z8encore000zco/configs/ostest/Make.defs | 2 +-
 boards/z80/z8/z8f64200100kit/configs/ostest/Make.defs | 2 +-
 tools/Config.mk   | 2 +-
 7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/boards/z16/z16f/z16f2800100zcog/scripts/Make.defs b/boards/z16/z16f/z16f2800100zcog/scripts/Make.defs
index f95ddbaf6d..31c00195d7 100644
--- a/boards/z16/z16f/z16f2800100zcog/scripts/Make.defs
+++ b/boards/z16/z16f/z16f2800100zcog/scripts/Make.defs
@@ -228,7 +228,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		"$(AR)" $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		"$(AR)" $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/boards/z80/ez80/ez80f910200kitg/scripts/Make.defs b/boards/z80/ez80/ez80f910200kitg/scripts/Make.defs
index b3c1e845bd..ae34dbee6f 100644
--- a/boards/z80/ez80/ez80f910200kitg/scripts/Make.defs
+++ b/boards/z80/ez80/ez80f910200kitg/scripts/Make.defs
@@ -243,7 +243,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		$(AR) $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		$(AR) $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/boards/z80/ez80/ez80f910200zco/scripts/Make.defs b/boards/z80/ez80/ez80f910200zco/scripts/Make.defs
index 678748ad91..91f8287f62 100644
--- a/boards/z80/ez80/ez80f910200zco/scripts/Make.defs
+++ b/boards/z80/ez80/ez80f910200zco/scripts/Make.defs
@@ -243,7 +243,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		$(AR) $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		$(AR) $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/boards/z80/ez80/makerlisp/scripts/Make.defs b/boards/z80/ez80/makerlisp/scripts/Make.defs
index bb86693056..0d292579bf 100644
--- a/boards/z80/ez80/makerlisp/scripts/Make.defs
+++ b/boards/z80/ez80/makerlisp/scripts/Make.defs
@@ -251,7 +251,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		$(AR) $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		$(AR) $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/boards/z80/z8/z8encore000zco/configs/ostest/Make.defs b/boards/z80/z8/z8encore000zco/configs/ostest/Make.defs
index 084569b02f..031fe09f23 100644
--- a/boards/z80/z8/z8encore000zco/configs/ostest/Make.defs
+++ b/boards/z80/z8/z8encore000zco/configs/ostest/Make.defs
@@ -258,7 +258,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		"$(AR)" $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		"$(AR)" $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/boards/z80/z8/z8f64200100kit/configs/ostest/Make.defs b/boards/z80/z8/z8f64200100kit/configs/ostest/Make.defs
index 649343d78a..c99bca531c 100644
--- a/boards/z80/z8/z8f64200100kit/configs/ostest/Make.defs
+++ b/boards/z80/z8/z8f64200100kit/configs/ostest/Make.defs
@@ -258,7 +258,7 @@ endef
 
 define ARCHIVE
 	for __obj in $(2) ; do \
-		"$(AR)" $(ARFLAGS) $1=-+$$__obj || { echo "$(AR) $1=-+$$__obj FAILED!" ; exit 1 ; } \
+		"$(AR)" $(ARFLAGS) $1=-+$$__obj \
 	done
 endef
 
diff --git a/tools/Config.mk b/tools/Config.mk
index dbdf129b4f..e02d1fbb76 100644
--- a/tools/Config.mk
+++ b/tools/Config.mk
@@ -219,7 +219,7 @@ define ARCHIVE
 endef
 else
 define ARCHIVE
-	$(AR) $1 $(2) || { echo "$(AR) $1 FAILED!" ; exit 1 ; }
+	$(AR) $1 $(2)
 endef
 endif
 
-- 
2.20.1

Re: Build problems with ZDS-II

[Gregory Nutt]

Here is a little more detail about the error:


  Here are the problems that I see now:

1. The eZ80 COMPILE target generates the .obj file without using the 
fully decorated object name.  For example, when it is supposed to 
generate:



mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj

It instead generates:

mkfatfs.obj

That should be easy to fix in the COMPILE and ASSEMBLE definitions.

2. The full path to the archive is

D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib

But by the time it gets to the ZDS-II librarian, it becomes:

D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib

I haven't figures out where the backslashes are being lost yet.

I am expecting that this explicit GCC command option will cause 
failures too:


./Makefile: $(call COMPILE, -fno-lto $<, $@)

That really should be dependent on CONFIG_ARCH_TOOLCHAIN_GNU. There 
should be an issue opened up on that.


These all seem like simple things, but I haven't solved them all yet.  
Makefiles are too difficult to debug!



Detailed output with V=1 and some instrumentation:

   make[2]: Entering directory
   '/cygdrive/d/Spuda/Documents/projects/nuttx/master/apps-fork/fsutils/mkfatfs'

   ### Here three files are compiled.  They still generate the
   undecorated object files.

   /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
   -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
   -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
   -NOigcase
   
-include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -warn -nodebug -NOsdiopt"
   
-stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -usrinc:'.' -define:_EZ80F91 -define:
   -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
   `cygpath -w " mkfatfs.c"`
   mkfatfs.c

   /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
   -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
   -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
   -NOigcase
   
-include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -warn -nodebug -NOsdiopt"
   
-stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -usrinc:'.' -define:_EZ80F91 -define:
   -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
   `cygpath -w " configfat.c"`
   configfat.c

   /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80cc.exe -warn
   -nodebug -optsize -keeplst -NOlist -NOlistinc -keepasm -chartype:S
   -promote -cpu:eZ80F91 -NOgenprintf -NOmodsect -asmsw:" -cpu:eZ80F91
   -NOigcase
   
-include:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -warn -nodebug -NOsdiopt"
   
-stdinc:'D:\Spuda\Documents\projects\nuttx\master\nuttx-fork\include;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\std;C:\ZiLOG\ZDSII_eZ80Acclaim!_5.3.3\include\zilog'
   -usrinc:'.' -define:_EZ80F91 -define:
   -usrinc:'D:\Spuda\Documents\projects\nuttx\master\apps-fork\include'
   `cygpath -w " writefat.c"`
   writefat.c

   ### Here is the ARCHIVE.  A debug echo shows that $1, $2m, and $AR
   are okay

   1= D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib
   2=
   
mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   
configfat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   
writefat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   AR=/cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80lib.exe

   ### This is the ARCHIVE loop.  Things are divided on separate lines
   to make it more readable

   for __obj in
   
mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   
configfat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   
writefat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj
   ; \
   do \
   /cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80lib.exe -quiet
   -warn
   "D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib"=-+$__obj
   || \
  { echo
   "/cygdrive/c/ZiLOG/ZDSII_eZ80Acclaim!_5.3.3/bin/ez80lib.exe
   "D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib"=-+$__obj
   FAILED!" ; exit 1 ; } \
   done

   ### This looks like the first call to $(AR).  The $(AR) is missing
   and seems to generate the error
   ### The library patch still seems good

   -quiet 

Re: Build problems with ZDS-II

[Gregory Nutt]

On 2/20/2020 11:17 AM, Xiang Xiao wrote:

Do you include my patch?

Yes

And does the same config pass the build yesterday?


Yesterday I could not see some failures because $(Q) was still there.  
So the archiver echo error output was being lost.  Things have gotten 
worse since yesterday, but I think most of the issues are on the ez80 
side.  Here are the problems that I see now:


1. The eZ80 COMPILE target generates the .obj file without using the 
fully decorated object name.  For example, when it is supposed to generate:


   
mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps-fork.fsutils.mkfatfs.obj

It instead generates:

   mkfatfs.obj

That should be easy to fix in the COMPILE and ASSEMBLE definitions.

2. The full path to the archive is

   D:\Spuda\Documents\projects\nuttx\master\apps-fork\libapps.lib

But by the time it gets to the ZDS-II librarian, it becomes:

   D:SpudaDocumentsprojectsnuttxmasterapps-forklibapps.lib

I haven't figures out where the backslashes are being lost yet.

I am expecting that this explicit GCC command option will cause failures 
too:


   ./Makefile: $(call COMPILE, -fno-lto $<, $@)

That really should be dependent on CONFIG_ARCH_TOOLCHAIN_GNU. There 
should be an issue opened up on that.


These all seem like simple things, but I haven't solved them all yet.  
Makefiles are too difficult to debug!


Greg

Re: Usrsocktest app example fails

[Oleg Evseev]

Turned on DEBUG_ASSERTIONS, DEBUG_NET_ERROR=y, DEBUG_NET_INFO=y,
DEBUG_NET_WARN=y, left only WakeWithSignal test in usrsocktest example, got
hardfault in debug assertion somewhere in semaphores

nsh> Starting unit-tests...
Testing group "WakeWithSignal" =>
usrsockdev_open: opening /dev/usrsock
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsockdev_close: closing /dev/usrsock
usrsock_event: events: 0002
connect_event: socket aborted.
usrsock_close: usockid=1; already closed.
usrsockdev_open: opening /dev/usrsock
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_event: request completed.
usrsockdev_pollnotify: Report events: 01
usrsock_event: events: 8000
socket_evenup_assert: Assertion failed at file:semaphore/sem_holder.c line:
128 task: usrsocktest

on attempt blocking connect
do_usrsock_blocking_close_thread:
  /* Attempt blocking connect. */
  ret = connect(test_sd[tidx], (FAR const struct sockaddr *),
sizeof(addr));
-> usrsock_connect:
  /* Wait for completion of request (or signal). */
  ret = net_lockedwait();


чт, 20 февр. 2020 г. в 13:19, Oleg Evseev :

> Hi all,
>
> Trying to run usrsocktest example from app:
> [image: изображение.png]
>
> 1) first two failed test in NoBlockRecv and BlockRecv fail because
> ret = recvfrom(sd, data, datalen, 0, (FAR struct sockaddr
> *), );
> fills sin_zero in remoteaddr with some notzero values.
>
> [image: изображение.png]
> 2) BasicGetSockName fails because usrsock_getsockname doesn't check addr
> for not null, so test with NULL addr do not get expected error.
>
> 3) WakeWithSignal after this fails hangs up the app.
>
> I'm not blaming anyone and do not complain, please do not be offended.
> Thanks for all this work, really, but I'm in deep wonder does anybody run
> this example at least once before? I thought that usrsock is quite stable
> and I would like to concentrate on cell modem driver development and not
> the net/usrsock stack itself in which I have very little knowledge.
> I'm still thinking that I've set something wrong, especially due to fact
> that I'm playing with it through px4 project in fact (but using latest
> original Nuttx).
>
> Thanks for any thoughts.
>
> --
> With regards, Oleg.
>

Build problems with ZDS-II

[Gregory Nutt]

Hi, Xiang, Chao,

I am building for the ez80-based  z20x board now and running into some 
problems.  I am getting warnings like this in every directory under apps:


   make[2]: Entering directory
   '/cygdrive/d/Spuda/Documents/projects/nuttx/master/apps/fsutils/mkfatfs'
   mkfatfs.c
   configfat.c
   writefat.c
   (Module: D:\Spuda\Documents\projects\nuttx\master\apps\libapps.lib)
   WARNING (610) --> Module
   
"mkfatfs.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps.fsutils.mkfatfs.obj"
   not found.
   (Module: D:\Spuda\Documents\projects\nuttx\master\apps\libapps.lib)
   WARNING (610) --> Module
   
"configfat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps.fsutils.mkfatfs.obj"
   not found.
   (Module: D:\Spuda\Documents\projects\nuttx\master\apps\libapps.lib)
   WARNING (610) --> Module
   
"writefat.cygdrive.d.Spuda.Documents.projects.nuttx.master.apps.fsutils.mkfatfs.obj"
   not found.
   make[2]: Leaving directory
   '/cygdrive/d/Spuda/Documents/projects/nuttx/master/apps/fsutils/mkfatfs'

That is a shorter example that illustrates the problem.  At the end of 
the successful compilation, I also get some linker errors that would 
seem to indicate that there is file corruption, but I cannot yet be 
certain of that.


Any thought?  The warnings are annoying if nothing else.

Greg

Re: CONFIG_BUILD_KERNEL questions

[Gregory Nutt]

what's the status of CONFIG_BUILD_KERNEL?
it seems only sama5 has the necessary up_ functions. is this right?
is there a way to run on emulators like qemu?


I have not used the kernel build in some time.  It has been used in 
products in the past so it is complete and usable but has some 
limitations and "opportunities" for design improvements.  This Wiki page 
provides the full status of the KERNEL build and support for processes 
under NuttX: 
https://cwiki.apache.org/confluence/display/NUTTX/Memory+Configurations


Only the sama5d4-ek:knsh configuration supports the KERNEL build at present.

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[David Sidrane]

DTCM and D-cache are different

You will need to add the cache clean and invalidate in the write/read
functions to support D-cache. If you open a PR on Git hub, I will have a
look at it.

For comparison an STM32F7/H7 have these functions in the correct palces.

David

-Original Message-
From: Thomas Axelsson [mailto:thomas.axels...@actia.se]
Sent: Thursday, February 20, 2020 6:12 AM
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no
caching, but after finding and turning off D-Cache in menuconfig, my board
enumerates as a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco 
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up
buffer problems

This sounds like a data cache problem.  One difference between the i.MXRT
and the LPC43 is that it has a data cache.  So you must flush the cache
before starting any DMA operation and invalidate the cache before reading
any DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson
 Date: 2/20/20  5:24 AM  (GMT-06:00) To:
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31
driver) - Set-up buffer problems

Hi,

I’m trying to get the IMXRT1060-EVK working as a USB device using the USB
OTG1 peripheral.

By comparing reference manuals, I’ve figured that the USB peripheral seems
to be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
registers and tweaked the initialization. I have made some ugly copies
(throwing in the PLL init in the driver) that will need to be cleaned up,
once the driver is working. Also, it is currently full of small hacks,
trying to get it to work. I have included  the almost unmodified, copied
LPC43 driver, in the patch as well, for comparison.

The driver is almost working, but I’ve stumbled on a problem with reading
the Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides
in RAM).

What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line
in USB trace image)The host sends Set Address (not visible in Linux usbmon
trace!) but the device reads the old Get Descriptor packet from
g_qh[0].setup and responds as if Get Descriptor  was sent. (Blue line and
following red text in USB trace image)

When playing around with the code I have sometimes found .setup to be all
zeroes, when the host does  Get Descriptor, Reset, . Meaning that
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB
controller.

I have also at one time managed to read .setup repeatedly, after the
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set
Address. However, I’m having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the
first setup package and not updated again, or sometimes updated with a large
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code
would skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the
device reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated
the trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH ...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<---
This should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch tools/configure.sh imxrt1060-evk:nsh cp downloads/defconfig
defconfig make olddefconfig make

Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB
Monitor with NSH).

(I've found that I have to toggle the boot config to  on SW7 and reset,
to be able to flash with J-Link after starting this NuttX config. It does

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[Thomas Axelsson]

That seems to be it! Thanks!

I was under the impression that not having DTCM enabled would mean no caching, 
but after finding and turning off D-Cache in menuconfig, my board enumerates as 
a USB device. Now to fix it for real.

BR
Thomas

-Original Message-
From: spudaneco  
Sent: den 20 februari 2020 13:41
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 
driver) - Set-up buffer problems 

Hi,
 
I’m trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.
 
By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT  registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included  the almost unmodified, copied LPC43 driver, in the patch as 
well, for comparison.
 
The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).
 
What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon trace!) 
but the device reads the old Get Descriptor packet from g_qh[0].setup and 
responds as if Get Descriptor  was sent. (Blue line and following red text in 
USB trace image)
 
When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by  the USB 
controller.
 
I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.
 
So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.
 
I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.
 
 
Any ideas on what might be going wrong or where to dig?
 
I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.
 
 
Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.
 
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt 
decode    8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode   
18: IMXRT_TRACEINTID_GETSETDESC   Interrupt decode    5: 
IMXRT_TRACEINTID_DISPATCH     ...
Interrupt entry 1: ENTRY     Interrupt 
entry 1: ENTRY    0081 Interrupt decode    
8: IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode    8: 
IMXRT_TRACEINTID_EP0SETUP    0001 Interrupt decode   18: 
IMXRT_TRACEINTID_GETSETDESC   <<--- This should have been 
SETADDRESS!
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
 
 
Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master 
apply the patch tools/configure.sh imxrt1060-evk:nsh cp downloads/defconfig 
defconfig make olddefconfig make
 
Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).
 
(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that
 issue.)
 
 
Thomas Axelsson
SW Developer
ACTIA Nordic AB
(part of ACTIA Group)
 
Mail:
thomas.axels...@actia.se

Web:
www.actia.se

 

 

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[spudaneco]

This sounds like a data cache problem.  One difference between the i.MXRT and 
the LPC43 is that it has a data cache.  So you must flush the cache before 
starting any DMA operation and invalidate the cache before reading any 
DMAdata.GregSent from Samsung tablet.
 Original message From: Thomas Axelsson 
 Date: 2/20/20  5:24 AM  (GMT-06:00) To: 
dev@nuttx.apache.org Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 
driver) - Set-up buffer problems 

Hi,
 
I’m trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.
 
By comparing reference manuals, I’ve figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I’ve 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT
 registers and tweaked the initialization. I have made some ugly copies 
(throwing in the PLL init in the driver) that will need to be cleaned up, once 
the driver is working. Also, it is currently full of small hacks, trying to get 
it to work. I have included
 the almost unmodified, copied LPC43 driver, in the patch as well, for 
comparison.
 
The driver is almost working, but I’ve stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).
 
What I’ve found is that

The host sends Get Descriptor and the device responds correctly. (Green line in 
USB trace image)The host sends Set Address (not visible in Linux usbmon trace!) 
but the device reads the old Get Descriptor packet from g_qh[0].setup and 
responds as if Get Descriptor
 was sent. (Blue line and following red text in USB trace image)
 
When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by
 the USB controller.
 
I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I’m having a hard time to reproduce it.
 
So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.
 
I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.
 
 
Any ideas on what might be going wrong or where to dig?
 
I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.
 
 
Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I’ve duplicated the 
trace lines in the code.
 
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
...
Interrupt entry 1: ENTRY    
Interrupt entry 1: ENTRY    0081
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode    8: IMXRT_TRACEINTID_EP0SETUP    0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode    5: IMXRT_TRACEINTID_DISPATCH    
 
 
Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch
tools/configure.sh imxrt1060-evk:nsh
cp downloads/defconfig defconfig
make olddefconfig
make
 
Flash board
Connect USBOTG1 (connector J9) to host.
Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).
 
(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that
 issue.)
 
 
Thomas Axelsson
SW Developer
ACTIA Nordic AB
(part of ACTIA Group)
 
Mail:
thomas.axels...@actia.se

Web:
www.actia.se

 

 

Re: Request to join Mailing List

[Nathan Hartman]

On Thu, Feb 20, 2020 at 6:13 AM Bhindhiya Raja
 wrote:

> Hi
>
> I would like to join the mailing list.


Hello,

Please send blank email to dev-subscr...@nuttx.apache.org.

Regards
Nathan

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[Thomas Axelsson]

Excuse the spam. I have added a .txt extension to defconfig. I'm hoping it will 
be included now.

From: Thomas Axelsson 
Sent: den 20 februari 2020 12:27
To: dev@nuttx.apache.org
Subject: RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Adding missing defconfig

From: Thomas Axelsson 
mailto:thomas.axels...@actia.se>>
Sent: den 20 februari 2020 12:24
To: dev@nuttx.apache.org
Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Hi,

I'm trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.

By comparing reference manuals, I've figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I've 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included the almost unmodified, copied LPC43 driver, in the patch as well, 
for comparison.

The driver is almost working, but I've stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).

What I've found is that

  1.  The host sends Get Descriptor and the device responds correctly. (Green 
line in USB trace image)
  2.  The host sends Set Address (not visible in Linux usbmon trace!) but the 
device reads the old Get Descriptor packet from g_qh[0].setup and responds as 
if Get Descriptor was sent. (Blue line and following red text in USB trace 
image)

When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by the USB 
controller.

I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I'm having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I've duplicated the 
trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH
...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch

tools/configure.sh imxrt1060-evk:nsh

cp downloads/defconfig defconfig

make olddefconfig

make



Flash board

Connect USBOTG1 (connector J9) to host.

Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).



(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that issue.)



Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se
Web: www.actia.se

[cid:image001.png@01D5E7E9.3B6B6D70]

#
# This file is autogenerated: PLEASE DO NOT EDIT IT.
#
# You can use "make menuconfig" to make any modifications to the installed 
.config file.
# You can then do "make savedefconfig" to generate a new defconfig file that 
includes your
# modifications.
#
CONFIG_ARCH="arm"
CONFIG_ARCH_BOARD="imxrt1060-evk"
CONFIG_ARCH_BOARD_IMXRT1060_EVK=y
CONFIG_ARCH_CHIP="imxrt"
CONFIG_ARCH_CHIP_IMXRT=y
CONFIG_ARCH_CHIP_MIMXRT1062DVL6A=y
CONFIG_ARCH_STACKDUMP=y
CONFIG_ARMV7M_DCACHE=y
CONFIG_ARMV7M_DCACHE_WRITETHROUGH=y
CONFIG_ARMV7M_ICACHE=y

RE: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer problems

[Thomas Axelsson]

Adding missing defconfig

From: Thomas Axelsson 
Sent: den 20 februari 2020 12:24
To: dev@nuttx.apache.org
Subject: IMXRT 1060 USB Device (copy of LPC43/LPC31 driver) - Set-up buffer 
problems

Hi,

I'm trying to get the IMXRT1060-EVK working as a USB device using the USB OTG1 
peripheral.

By comparing reference manuals, I've figured that the USB peripheral seems to 
be identical to the one found in NXP LPC43xx (and LPC31xx). As such, I've 
copied lpc43_usb0dev.c, replaced all the registers with the IMX RT registers 
and tweaked the initialization. I have made some ugly copies (throwing in the 
PLL init in the driver) that will need to be cleaned up, once the driver is 
working. Also, it is currently full of small hacks, trying to get it to work. I 
have included the almost unmodified, copied LPC43 driver, in the patch as well, 
for comparison.

The driver is almost working, but I've stumbled on a problem with reading the 
Set-up buffer in the EP0 Queue Head (g_qh[0].setup) (struct that resides in 
RAM).

What I've found is that

  1.  The host sends Get Descriptor and the device responds correctly. (Green 
line in USB trace image)
  2.  The host sends Set Address (not visible in Linux usbmon trace!) but the 
device reads the old Get Descriptor packet from g_qh[0].setup and responds as 
if Get Descriptor was sent. (Blue line and following red text in USB trace 
image)

When playing around with the code I have sometimes found .setup to be all 
zeroes, when the host does  Get Descriptor, Reset, . Meaning that 
the zeroes written by imxrt_usbreset() has not been overwritten by the USB 
controller.

I have also at one time managed to read .setup repeatedly, after the 
ENDPTSETUPSTAT has been set, until the value changed and gotten the Set 
Address. However, I'm having a hard time to reproduce it.

So it seems that the data in g_qh[0].setup is only filled correctly for the 
first setup package and not updated again, or sometimes updated with a large 
delay.

I have tried sprinkling some volatile, in case the imxrt_readsetup() code would 
skip the memory access, without success.


Any ideas on what might be going wrong or where to dig?

I have included the current state of the driver (imxrt_usbdev.c) and a 
patch+defconfig if someone wants to play on an IMXRT EVK. The patch was 
generated against NuttX master branch.


Here is a snippet from the console output on the device, showing how the device 
reacts to Get Descriptor followed by Set Address.
Please note that ENTRY and EP0SETUP is doubly traced since I've duplicated the 
trace lines in the code.

Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC  
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH
...
Interrupt entry 1: ENTRY
Interrupt entry 1: ENTRY0081
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode8: IMXRT_TRACEINTID_EP0SETUP0001
Interrupt decode   18: IMXRT_TRACEINTID_GETSETDESC   <<--- This 
should have been SETADDRESS!
Interrupt decode5: IMXRT_TRACEINTID_DISPATCH


Testing the patch:
git checkout 90839b41f92aa01f1b0b24d18ee62e6efa4077d5  # or current master
apply the patch

tools/configure.sh imxrt1060-evk:nsh

cp downloads/defconfig defconfig

make olddefconfig

make



Flash board

Connect USBOTG1 (connector J9) to host.

Press  in nsh to see the usbtrace (I did not manage to use the USB 
Monitor with NSH).



(I've found that I have to toggle the boot config to  on SW7 and reset, to 
be able to flash with J-Link after starting this NuttX config. It does not 
happen in my dev code, so I'm ignoring that issue.)



Thomas Axelsson
SW Developer
ACTIA Nordic AB (part of ACTIA Group)

Mail: thomas.axels...@actia.se
Web: www.actia.se

[cid:image001.png@01D5E7E9.029B3520]

Request to join Mailing List

[Bhindhiya Raja]

Hi

I would like to join the mailing list.

Regards
Bhindhiya Raja

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.

Usrsocktest app example fails

[Oleg Evseev]

Hi all,

Trying to run usrsocktest example from app:
[image: изображение.png]

1) first two failed test in NoBlockRecv and BlockRecv fail because
ret = recvfrom(sd, data, datalen, 0, (FAR struct sockaddr
*), );
fills sin_zero in remoteaddr with some notzero values.

[image: изображение.png]
2) BasicGetSockName fails because usrsock_getsockname doesn't check addr
for not null, so test with NULL addr do not get expected error.

3) WakeWithSignal after this fails hangs up the app.

I'm not blaming anyone and do not complain, please do not be offended.
Thanks for all this work, really, but I'm in deep wonder does anybody run
this example at least once before? I thought that usrsock is quite stable
and I would like to concentrate on cell modem driver development and not
the net/usrsock stack itself in which I have very little knowledge.
I'm still thinking that I've set something wrong, especially due to fact
that I'm playing with it through px4 project in fact (but using latest
original Nuttx).

Thanks for any thoughts.

-- 
With regards, Oleg.

Re: A x86-64 port of nuttx with Linux compatibility layer

[Yang Chung Fan]

Seems I have finally got my apache list setup working properly.

I think I need to make some clarification for my current directory
setup in the repository.

The idea was to minimize the modifications to both Linux and Nuttx
while providing the ability to run them in parallel and accessing each
other's benefit.
Therefore, I used jailhouse hypervisor which is a simple hardware
enabled partitioning hypervisor.
Only bootloader is needed for porting a existing RTOS to jailhouse if
the architecture is already supported by the RTOS.

About the nuttx directories:
 * I tried not to modify the architecture independent part of nuttx,
but I might did some in the early day of development, when I was using
dynamic linking interface instead of system call interface.
 * arch/x86_64: contains my port of the x86_64 Nuttx, I tried to
maintain the same directory structure as i486 port, but for x86_64, I
really had a difficulty to separate common, intel64, broadwell
architecture part perfectly.
 * arch/x86_64/src/linux_subsystem: This is where the Linux
compatibility layer lives and licensing can be painful.
 * config/jailhouse-intel64: This directory contains the drivers and
bootloader related to jailhouse. I tried to make a clean split of the
Jailhouse related components and pure x86_64 part, but I might have
failed some where.

I do think that we can:
 1. Find and revert any unnecessary change to the Nuttx kernel.
 2. Clean up the arch/x86_64 code, decouple it from Jailhouse
completely, and provide a qemu port.
 3. Try to work out a working development environment with qemu,
instead of jailhouse, for the sake that everyone can try it. (Because
setting up Jailhouse is really a pain in the ass).
 4. We can continue onto integrate the Linux compatibility layer and
Linux binary loader after these are properly done.


Yang



--
Yang Chung Fan (楊宗凡) (ヤン　ゾン　ファン)
Member of Softlab, Tsukuba University , Japan
Email: sonic.tw...@gmail.com

CONFIG_BUILD_KERNEL questions

[Takashi Yamamoto]

hi,

what's the status of CONFIG_BUILD_KERNEL?
it seems only sama5 has the necessary up_ functions. is this right?
is there a way to run on emulators like qemu?

thank you