From mboxrd@z Thu Jan 1 00:00:00 1970 From: Marek Vasut Date: Fri, 10 Jan 2020 04:56:23 +0100 Subject: [PATCH 3/3] mtd: rawnand: denali: Do not reset the block before booting the kernel In-Reply-To: References: <20200110001417.82917-1-marex@denx.de> <20200110001417.82917-3-marex@denx.de> Message-ID: List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de On 1/10/20 4:09 AM, Masahiro Yamada wrote: > On Fri, Jan 10, 2020 at 9:14 AM Marek Vasut 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? 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 either read bogus values and fail to use the NAND or get stuck on register access. > (BTW, the situation is worse on the UniPhier platform. > The kernel will crash because the register access never respond.) So uniphier is even worse off.