Flash Device API

Gedare Bloom gedare at rtems.org
Fri Mar 17 21:24:14 UTC 2023

Thank you Aaron for contributing this. I have a few comments below,
and I'll also give some comments on your code shortly.

On Fri, Mar 17, 2023 at 1:34 AM Sebastian Huber
<sebastian.huber at embedded-brains.de> wrote:
> On 16.03.23 23:07, Chris Johns wrote:
> > On 16/3/2023 6:13 pm, Sebastian Huber wrote:
> >> Hello Aaron,
> >>
> >> this API seems to be RTEMS-specific. Maybe we should simply pick up an existing
> >> solution which is in more wide spread use, for example:
> >>
> >> https://docs.zephyrproject.org/latest/hardware/peripherals/flash.html
> >
> > That interface seems Zepher specific and looks to me like a series of calls that
> > appear reasonable as a list to cover.
> The Zephyr API has drivers for a couple of chips:
> https://github.com/zephyrproject-rtos/zephyr/tree/main/drivers/flash
That code looks very zephyr-oriented. I think it would be a challenge
to go first toward porting this API, if it requires substantial
modifications of the upstream drivers to also use them, then it is
more of a maintenance burden than the probable benefits of the code
reuse. As a starting point, I do see a bespoke RTEMS implementation as
a suitable place to begin. But, it would be good to understand the
alternative flash driver frameworks that are out there, and what may
be pros/cons of adopting them.

> > The patch Aaron has posted is a driver. I
> > prefer a driver like we have for I2C, SPI etc because the of support it brings.
> The I2C and SPI APIs are ported from Linux, so not RTEMS-specific.
> >
> > The initial set of ioctl commands is small to start with. If you feel we should
> > offer more I suggest they get added once this is merged.
> >
> > Is the change OK?
> I am not opposed to commit this API, however, I don't think it is a step
> forward. It is yet another RTEMS-specific API. It has no related
> documentation patches. The API has no high level user (for example
> JAFFS2). The API has no implementation. It has no tests. It has no
> driver framework (ONFI, JEDEC). It has no example driver. It has no
> Doxygen documentation. The coding style of the new file has nothing to
> do with the RTEMS coding style.

I think the provided code appears to be a good starting point.  I
would request that you might add Doxygen something aligned with what
we have for the i2c or spi would be good.

In addition to the shell command addition, can you create/extend a
testsuite for exercising the API?

I will address the code directly also, but these high-level additions
will greatly improve the submission of a new API. Unfortunately, my
work on code formatting is not quite complete enough to rely on it for
fixing any style issues. I'll do what I can to guide you through that.


More information about the devel mailing list