Re: Warnings in Renesas common files

[Bhindhiya Raja]

Hello Greg and Nathan,

Any input on the warnings generated due to the g_current_regs volatile type 
qualifier?

Best Regards,

Bhindhiya Raja


SBU | Engineer

TATA ELXSI LIMITED

ITPB Road Whitefield

Bengaluru 560 048 India

www.tataelxsi.com


From: Nathan Hartman 
Sent: Saturday, September 5, 2020 3:51 AM
To: dev@nuttx.apache.org 
Subject: Re: Warnings in Renesas common files


 **This is an external email. Please check the sender’s full email address (not 
just the sender name) and exercise caution before you respond or click any 
embedded link/attachment.**


On Fri, Sep 4, 2020 at 9:40 AM Bhindhiya Raja
 wrote:
>
> Hello Nathan,
>
> Thank you for your response. We have submitted 2 separate PRs as recommended 
> by you to resolve warnings 6 (#1695) and 8 (#1702).
>
> About warnings 1 to 4, we understand that casting away the 'volatile' type 
> qualifier of a variable should be avoided if possible. Can we consider 
> modifying the prototype of the function up_copystate() in up_internal.h file,
> from:
> void up_copystate(uint32_t *dest, uint32_t *src);
> to:
> void up_copystate(uint32_t *dest, volatile uint32_t *src);
> in order to resolve this warning.
>
> We have tried the above fix in our local repository and checked build.
> We found that warnings 1 to 4 are resolved, however, it generates a new 
> warning in file:
> arch/renesas/src/rx65n/rx65n_copystate.c: passing argument 2 of 
> ‘up_copystate’ discards ‘volatile’ qualifier from pointer target type
> memcpy(dest, src, XCPTCONTEXT_SIZE);
>
> expected ‘const void *’ but argument is of type ‘volatile uint32_t *’
> FAR void *memcpy(FAR void *dest, FAR const void *src, size_t n);
>
> This can be resolved by typecasting the variables when calling memcpy() alone.
>
> As these files are common to other Renesas architectures as well, please 
> confirm if the above modifications are okay.


Hello Bhindhiya,

I am not sure what is the best choice here. I looked through NuttX
sources and I did not see any up_copystate() (for any arch) that had
volatile qualifiers. That said, looking at the call to up_copystate()
in up_unblock_task(), g_current_regs is indeed volatile (for good
reasons), so I wonder if we should propagate that as far as possible,
until the memcpy(), like you're suggesting, or, alternatively, if it
is safe to discard volatile like is being done already, because we are
switching tasks.

I need to think about this some more.

Maybe Greg will share some of his wisdom with us. :-)

Nathan

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

Re: Query on USB Hub device node creation

[Anjana]

Thank you for the confirmation



Regards,

Anjana


From: Brennan Ashton 
Sent: 11 September 2020 23:16
To: dev@nuttx.apache.org 
Subject: Re: Query on USB Hub device node creation


 **This is an external email. Please check the sender’s full email address (not 
just the sender name) and exercise caution before you respond or click any 
embedded link/attachment.**


On Fri, Sep 11, 2020 at 10:39 AM Schock, Johannes - NIVUS GmbH
 wrote:
>
> > 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

There was talk at one point of adding support for the /dev/usbN like
exists in freeBSD which would also allow for libusb like functionality
https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.freebsd.org%2Fcgi%2Fman.cgi%3Fquery%3Dusb%26sektion%3D4%26manpath%3DFreeBSD%2B4.10-RELEASE&data=02%7C01%7CAnjana%40tataelxsi.co.in%7C83981cfb545e4cbe79a408d8567a99aa%7Cad6a39dd96b6436882daf2ec4d92e26a%7C0%7C0%7C637354431864032913&sdata=oVm1f%2FO3fh8Ty%2FwXsug4XpobW%2BpCf3viEltt6yeGz4A%3D&reserved=0
but none of this work has been done

--Brennan

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.

Kinetis QSPI MTD driver

[Schock, Johannes - NIVUS GmbH]

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

[OT] Can one person run an open source project alone?

[Gregory Nutt]

I ran across this and thought it interesting.  I decided to share: 
https://stackoverflow.blog/2020/09/09/open-source-governance-benevolent-dictator-or-decision-by-committee/


Several things resonate.

Configuration Specific ROMFS rcS Files

[Anthony Merlino]

Hi all,

I would like to come up with a way of having a *configuration-specific*
ROMFS image that is automatically generated as part of the build system.

I see that Xiang has recently made this commit,
https://github.com/apache/incubator-nuttx/pull/793/files
which definitely gets me closer to doing what I want.

But in this method, the etc/ folder is stored in the board src/ directory.
This means all configurations for this board have the same ROMFS image,
which is not what I'm looking to do.

The issue I see is that the only time the configuration folder is known is
when configure.sh is run.

I know that I could use the NSH_CUSTOMROMFS and point at a directory, but
this requires each configuration to then define a path to itself, and still
doesn't help me auto-generate as part of the build system.

Hoping someone might suggest something clever. Everything I've come up with
seems like a kludge. Maybe symlink the files into the board/ directory as
part of the configuration process?

Best,
Anthony