From mboxrd@z Thu Jan 1 00:00:00 1970 From: Heiko Schocher Date: Tue, 26 Apr 2016 07:17:56 +0200 Subject: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot In-Reply-To: <20160425173646.GM3732@bill-the-cat> References: <20160425164314.15c3fc94@bbrezillon> <20160425173646.GM3732@bill-the-cat> Message-ID: <571EFA04.4000803@denx.de> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hello Tom, Boris, Am 25.04.2016 um 19:36 schrieb Tom Rini: > On Mon, Apr 25, 2016 at 04:43:14PM +0200, Boris Brezillon wrote: > >> Hi Scott, >> >> I've recently contributed a lot of MTD/NAND related patches (and intend >> to continue doing so). Some of them are transversal changes touching the >> MTD and NAND framework internals, which implies patching all NAND >> drivers along with the core changes. >> >> All those changes are required to properly handle modern NANDs (MLC/TLC >> NANDs), and I need them to add proper NAND support to the sunxi >> platform (and more particularly to the C.H.I.P from NextThing Co.). >> >> So my question is, how should I port those changes to U-Boot? I see >> that your doing "synchronization commits", but in my case this mean >> including a bunch of driver specific changes into this "sync commit". >> >> I think it's also worth mentioning that I plan to heavily rework the >> Linux NAND framework to improve NAND performances on modern NAND >> controllers and clarify the NAND chip / NAND controller concepts, and >> other people are also working on merging the BBT code of the NAND and >> OneNAND framework. Which unfortunately means that we're not done porting >> invasive changes to U-Boot :-/. >> >> Any advice is welcome. > > I suppose my first suggestion would be to sync the kernel back into > U-Boot more frequently. With our bi-monthly release cycle it shouldn't > be too hard to pick a window to grab the current kernel release and > bring it over. I think the more stuff we let build up prior to syncing > the harder it will be. Yes, the same applies for UBI/UBIFS. I have no real strategy yet for this. I think also, we need when doing such a sync a better testframe- work, which tests on ideally a lot of boards the new versions ... Without this, it is very difficult not to break existing boards with such a sync ... especially MTD is tricky, I think, because a lot of boards use it ... I know I am nerving with my tbot [1], but it is may a solution for this. Also, as the UBI/UIFS case may show, it is not always a trivial job to do such a sync, as concepts in Linux changes ... bye, Heiko [1] https://github.com/hsdenx/tbot -- DENX Software Engineering GmbH, Managing Director: Wolfgang Denk HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany