[PATCH 3/3] mtd: rawnand: denali: Do not reset the block before booting the kernel

[Masahiro Yamada]

On Mon, Jan 13, 2020 at 8:11 PM Marek Vasut <marex at denx.de> wrote:
>
> On 1/10/20 6:26 AM, Masahiro Yamada wrote:
> > On Fri, Jan 10, 2020 at 1:05 PM Marek Vasut <marex at denx.de> wrote:
> >>
> >> On 1/10/20 4:09 AM, Masahiro Yamada wrote:
> >>> On Fri, Jan 10, 2020 at 9:14 AM Marek Vasut <marex at denx.de> wrote:
> >>>>
> >>>> The Denali NAND block loses configuration when put in reset.
> >>>> Specifically, RB_PIN_ENABLED, CHIP_ENABLE_DONT_CARE,
> >>>> SPARE_AREA_SKIP_BYTES and SPARE_AREA_MARKER are lost.
> >>>> Since mainline Linux depends on the configuration programmed
> >>>> into the Denali NAND controller by the bootloader, do not
> >>>> reset the controller before starting the kernel, otherwise
> >>>> the kernel will read bogus values and fail to use the NAND.
> >>>
> >>> I think this log is not directly describing the issue.
> >>> It is not a matter of reading bogus values.
> >>> You cannot use the hardware under the reset state in the first place.
> >>>
> >>> How about describing the root cause?
> >>> For example,
> >>>
> >>> The denali driver in the mainline Linux does not support the reset
> >>> control yet. Do not reset the controller before starting the kernel,
> >>> otherwise the kernel cannot deassert the reset of the NAND controller.
> >>
> >> Is this better?
> >
> > I do not think so.
> >
> > Most of the description is just redundant.
> >
> > Hardware under the reset state does not work in any way.
> > The mainline kernel cannot deassert the NAND controller reset by itself.
> > That's all.
>
> That's only applicable to current state of things.


Yes, I said the current state of the mainline kernel
(since I am not a forecaster)



> Can you provide better description ?


I did already:

https://lists.denx.de/pipermail/u-boot/2020-January/395878.html



Who cares about the SPARE_AREA_SKIP_BYTES value
under the situation where you cannot deassert the reset?


> Note that on SoCFPGA, the behavior
> is exactly as documented here. Maybe it's different on Socionext ?


The behavior of the NAND controller on Socionext SoCs is this:
"It does not work while its reset signal is asserted."

I guess it is the same on SOCFPGA.

I have never seen such hardware that works
with its reset signal asserted.





--
Best Regards
Masahiro Yamada