[PATCH rtems-docs 2/2] user/zynqmp: Add NAND driver information

[Kinsey Moore]

On Tue, Mar 21, 2023 at 9:20 PM Chris Johns <chrisj at rtems.org> wrote:

> On 22/3/2023 1:18 pm, Kinsey Moore wrote:
> > On Tue, Mar 21, 2023 at 7:39 PM Chris Johns <chrisj at rtems.org
> > <mailto:chrisj at rtems.org>> wrote:
> >
> >     On 22/3/2023 7:00 am, Kinsey Moore wrote:
> >     > ---
> >     >  user/bsps/aarch64/xilinx-zynqmp.rst | 9 +++++++++
> >     >  1 file changed, 9 insertions(+)
> >     >
> >     > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst
> >     b/user/bsps/aarch64/xilinx-zynqmp.rst
> >     > index 4de0115..e30c3f6 100644
> >     > --- a/user/bsps/aarch64/xilinx-zynqmp.rst
> >     > +++ b/user/bsps/aarch64/xilinx-zynqmp.rst
> >     > @@ -250,6 +250,15 @@ Console Driver
> >     >  The console driver supports the default Qemu emulated ARM PL011
> PrimeCell
> >     UART
> >     >  as well as the physical ARM PL011 PrimeCell UART in the ZynqMP
> hardware.
> >     >
> >     > +NAND Controller Driver
> >     > +----------------------
> >     > +
> >     > +The ZynqMP BSP has a NAND controller driver which allows writing
> to and
> >     reading
> >     > +from one or more attached NAND chips. This driver was imported
> from the
> >     Xilinx
> >     > +embeddedsw repository and requires the clock to be configured
> since it is a
> >     > +polling driver and not interrupt-driven. This driver is only
> available for
> >     > +hardware BSPs since QEMU does not emulate the NAND controller.
> >
> >     Is the JFFS support that uses this driver for production or just an
> example?
> >
> >     I ask because the QSPI driver takes control of the whole flash and
> that is
> >     confusing if you run an app that has a boot image in the same device
> because the
> >     JFFS erases it.
> >
> >
> > The JFFS2 glue in the ZynqMP BSP (both NAND and NOR) is perfectly usable
> in
> > production, but it does not encompass every use case that may exist
> which is why
> > it is not run by default. The user would need to customize their own
> version of
> > the glue code if they have requirements beyond "use the whole device".
>
> Is this worth explaining? It confused us when we played with the code.
>

The NAND glue code makes it pretty clear if you read the blurb at the top
of the implementation file. It appears that the NOR glue code does not have
a similar blurb, but clearly it should.

Maybe the explanation should be in the header with the function definition,
instead?

What was the expectation of functionality when you provided the device
control struct instance to the JFFS2 init function with no additional
parameters?

Kinsey
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20230321/35550886/attachment-0001.htm>