Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S943050AbcJ0OkP (ORCPT ); Thu, 27 Oct 2016 10:40:15 -0400 Received: from b.ns.miles-group.at ([95.130.255.144]:44723 "EHLO radon.swed.at" rhost-flags-OK-OK-OK-FAIL) by vger.kernel.org with ESMTP id S1755427AbcJ0NwF (ORCPT ); Thu, 27 Oct 2016 09:52:05 -0400 Subject: Re: UBIFS LEB properties tree with odd addresses To: Naga Sureshkumar Relli , Christoph Hellwig References: Cc: "dwmw2@infradead.org" , "computersforpeace@gmail.com" , "dedekind1@gmail.com" , "adrian.hunter@intel.com" , "michal.simek@xilinx.com" , Punnaiah Choudary Kalluri , "linux-mtd@lists.infradead.org" , "linux-kernel@vger.kernel.org" , Boris Brezillon From: Richard Weinberger Message-ID: Date: Thu, 27 Oct 2016 14:51:55 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2158 Lines: 56 Naga Sureshkumar Relli, On 26.10.2016 14:11, Naga Sureshkumar Relli wrote: > Hi Richard, > > -----Original Message----- > From: Richard Weinberger [mailto:richard@nod.at] > Sent: Wednesday, October 26, 2016 2:44 AM > To: Naga Sureshkumar Relli ; Christoph Hellwig > Cc: dwmw2@infradead.org; computersforpeace@gmail.com; dedekind1@gmail.com; adrian.hunter@intel.com; michal.simek@xilinx.com; Punnaiah Choudary Kalluri ; linux-mtd@lists.infradead.org; linux-kernel@vger.kernel.org; Boris Brezillon > Subject: Re: UBIFS LEB properties tree with odd addresses > > Naga Sureshkumar Relli, >> Even bytes i.e. 0, 2, 4,... are transmitted on Lower Data Bus >> Odd bytes i.e. 1, 3, 5,.. are transmitted on Upper Data Bus. > >> But these details are hidden from UBI? > > Yes, Our controller driver will take care of these byte striping. > >> So for temporary hack we did the following change In fs/ubifs/lpt.c In >> do_calc_lpt_geom(), added the following >> + if (c->pnode_sz % 2) >> + c->pnode_sz += 1; >> + if (c->ltab_sz % 2) >> + c->ltab_sz += 1; >> >> Please kindly suggest, I need your inputs, changing the pnode_sz and ltab_sz to even in lpt.c, will it impact on any others? > >> Hmm, the calculations in lpt.c use basic properties of the MTD (number of blocks, etc...). >> Can you please double check which property causes the failure and also verify whether the MTD driver provides correct properties. i.e. page sizes, block size, number of blocks, ... > > Yes, only pnode_sz and ltab_sz are odd values Hm, these values depend only on basic MTD prperties AFAICT. > And MTD info, here are my logs > In Single Flash mode: > Mtd->erasesize = 64KiB > Mtd->size = 64MiB > Mtd->numeraseregions = 0 > Nor->pagesize = 256 > > In Dual parallel mode: > Mtd->erasesize = 128KiB > Mtd->size = 128MiB > Mtd->numeraseregions = 0 > Nor->pagesize = 512 How does UBI report them? Maybe you miss some bit and set incorrect MTD properties. A 128MiB MTD with 128KiB erase size is nothing special. Thanks, //richard