<meta http-equiv="Content-Type" content="text/html; charset=utf-8"><div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Mar 21, 2023 at 9:20 PM Chris Johns <<a href="mailto:chrisj@rtems.org">chrisj@rtems.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 22/3/2023 1:18 pm, Kinsey Moore wrote:<br>
> On Tue, Mar 21, 2023 at 7:39 PM Chris Johns <<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a><br>
> <mailto:<a href="mailto:chrisj@rtems.org" target="_blank">chrisj@rtems.org</a>>> wrote:<br>
> <br>
>     On 22/3/2023 7:00 am, Kinsey Moore wrote:<br>
>     > ---<br>
>     >  user/bsps/aarch64/xilinx-zynqmp.rst | 9 +++++++++<br>
>     >  1 file changed, 9 insertions(+)<br>
>     ><br>
>     > diff --git a/user/bsps/aarch64/xilinx-zynqmp.rst<br>
>     b/user/bsps/aarch64/xilinx-zynqmp.rst<br>
>     > index 4de0115..e30c3f6 100644<br>
>     > --- a/user/bsps/aarch64/xilinx-zynqmp.rst<br>
>     > +++ b/user/bsps/aarch64/xilinx-zynqmp.rst<br>
>     > @@ -250,6 +250,15 @@ Console Driver<br>
>     >  The console driver supports the default Qemu emulated ARM PL011 PrimeCell<br>
>     UART<br>
>     >  as well as the physical ARM PL011 PrimeCell UART in the ZynqMP hardware.<br>
>     > <br>
>     > +NAND Controller Driver<br>
>     > +----------------------<br>
>     > +<br>
>     > +The ZynqMP BSP has a NAND controller driver which allows writing to and<br>
>     reading<br>
>     > +from one or more attached NAND chips. This driver was imported from the<br>
>     Xilinx<br>
>     > +embeddedsw repository and requires the clock to be configured since it is a<br>
>     > +polling driver and not interrupt-driven. This driver is only available for<br>
>     > +hardware BSPs since QEMU does not emulate the NAND controller.<br>
> <br>
>     Is the JFFS support that uses this driver for production or just an example?<br>
> <br>
>     I ask because the QSPI driver takes control of the whole flash and that is<br>
>     confusing if you run an app that has a boot image in the same device because the<br>
>     JFFS erases it.<br>
> <br>
> <br>
> The JFFS2 glue in the ZynqMP BSP (both NAND and NOR) is perfectly usable in<br>
> production, but it does not encompass every use case that may exist which is why<br>
> it is not run by default. The user would need to customize their own version of<br>
> the glue code if they have requirements beyond "use the whole device".<br>
<br>
Is this worth explaining? It confused us when we played with the code.<br></blockquote><div><br></div><div><div>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.</div><div><br></div><div>Maybe the explanation should be in the header with the function definition, instead?</div><div><br></div><div>What
 was the expectation of functionality when you provided the device control struct instance to the JFFS2 init function with no additional parameters?</div><div><br></div><div>Kinsey</div> </div></div></div>