On 1/10/20 6:26 AM, Masahiro Yamada wrote: > On Fri, Jan 10, 2020 at 1:05 PM Marek Vasut <ma...@denx.de> wrote: >> >> On 1/10/20 4:09 AM, Masahiro Yamada wrote: >>> On Fri, Jan 10, 2020 at 9:14 AM Marek Vasut <ma...@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. Can you provide better description ? Note that on SoCFPGA, the behavior is exactly as documented here. Maybe it's different on Socionext ?
