drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.
include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registra
drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.
include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registratio
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, 21 October 2020.
The report for your podling will form a part of the
drivers/
should be holding internal to the driver interfaces, such register
definitions, low level communication interfaces readreg, writereg,
etc... that might be shared across implementations.
include/nuttx//.h
should hold the interfaces/types required to interact with the driver,
registrati
I am a little confused by what should be stored in the header files
for drivers in these two locations and I do not want to further any
existing mistakes:
include/nuttx//.h
and
drivers/
To mean it seems it should be organized like this:
drivers/
should be holding internal to the driver interface
Bhindhiya,
Why not follow the approach taken by other arch?
On Fri, Sep 18, 2020 at 9:34 PM Bhindhiya Raja
wrote:
>
> Hello Team,
>
> We are trying to include Renesas RX65N architecture in GitHub pre-check which
> requires code to have 0 warnings to be successful.
>
> Call to up_copystate() in t
Well,
I don't know how to explain, but I was reviewing here the process for
setup, writing down the commands that I used ... and now everything is
working fine. :-/
Maybe during yesterday's tests maybe something may be lost
during menuconfig.
I am sorry for the inconvenience.
But ... maybe I fo
By the way, the signature of this problem is corruption of either the
first or last 16 bytes of a 512-byte sector.
The M7 cache line size is 32 bytes. The standard Nuttx malloc uses a
16-byte alignment. Losing 16-bytes of a FAT table or directory will
cause all sorts of strange things to occur.
Just a thought
On M7 devices, the DMA buffers need to be cache line aligned. Nuttx has
special malloc functions configurable for FAT buffers.
Also, I'm not sure the cache invalidate code was tested well for
store-into cache mode. Store-through was known to be working.
-Bob
On Fri, Sep 18, 2
