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

[Chris Johns]

On 22/3/2023 1:32 pm, Kinsey Moore wrote:
> On Tue, Mar 21, 2023 at 9:20 PM Chris Johns <chrisj at rtems.org
> <mailto: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>
>     > <mailto: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.

Ah that would help.

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

Aaron is working on an API for flash so maybe we wait and once done moving to
that would make it since.

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

I am not sure. I have not look into the detail for a number of years now.

Chris