On 22/3/2023 1:18 pm, Kinsey Moore wrote: > On Tue, Mar 21, 2023 at 7:39 PM Chris Johns <chr...@rtems.org > <mailto:chr...@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. Chris _______________________________________________ devel mailing list devel@rtems.org http://lists.rtems.org/mailman/listinfo/devel
