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