On Wed, Apr 24, 2019 at 05:04:38AM +0000, Naga Sureshkumar Relli wrote: > > You previously used cond_resched (via nand_wait_ready) here. Why did you > > change it to > > cpu_relax()? > I just replicated the pl353_wait_for_ecc_done() API definition. > But did you see any issue with this? > Anyway I will replace it with cond_resched(), instead of cpu_releax()
This was an observation and it made me ask for reasons. I did not have any practical issues here. > Did you follow the same thing that you tried earlier? > i.e. updated "nand-bus-width" property and "nand-ecc-mode" ? Yes, I used the same device tree that made v13 partially work here. > > After trying the driver, the flash chip was bricked. Neither the old driver > > nor the uboot-xlnx > > driver nor the Xilinx fsbl are able to talk to the chip afterwards. This > > behaviour persists even > > after a full power cycle. I'll try reinitializing the flash chip next. I've > > only seen this behaviour > > once, so there is a slight chance that the cause is something else. > Sometimes I also faced the same problem during driver development. > What I did is, in standalone nandps driver example, I forcibly created BBT > in the init and once > it is done. I just reloaded the actual example. Then after wards u-boot and > Linux are able to scan > the BBT. I confirm. It was just the BBT being bad. It can also be recreated using u-boot with "nand scrib.chip". I also spent some time reviewing the code and will send another mail about that. Helmut
