All of lore.kernel.org
 help / color / mirror / Atom feed
From: Heiko Schocher <hs@denx.de>
To: Tom Rini <trini@konsulko.com>
Cc: Boris Brezillon <boris.brezillon@free-electrons.com>,
	Marek Vasut <marex@denx.de>,
	Thomas Petazzoni <thomas.petazzoni@free-electrons.com>,
	Richard Weinberger <richard@nod.at>,
	Scott Wood <oss@buserror.net>,
	u-boot@lists.denx.de,
	"linux-sunxi@googlegroups.com" <linux-sunxi@googlegroups.com>,
	"linux-mtd@lists.infradead.org" <linux-mtd@lists.infradead.org>,
	Scott Wood <scottwood@freescale.com>,
	Alexander Kaplan <alex@nextthing.co>,
	Brian Norris <computersforpeace@gmail.com>
Subject: Re: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
Date: Tue, 26 Apr 2016 07:17:56 +0200	[thread overview]
Message-ID: <571EFA04.4000803@denx.de> (raw)
In-Reply-To: <20160425173646.GM3732@bill-the-cat>

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

WARNING: multiple messages have this Message-ID (diff)
From: Heiko Schocher <hs@denx.de>
To: u-boot@lists.denx.de
Subject: [U-Boot] Porting Linux's MTD/NAND changes into U-Boot
Date: Tue, 26 Apr 2016 07:17:56 +0200	[thread overview]
Message-ID: <571EFA04.4000803@denx.de> (raw)
In-Reply-To: <20160425173646.GM3732@bill-the-cat>

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

  parent reply	other threads:[~2016-04-26  5:18 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-04-25 14:43 Porting Linux's MTD/NAND changes into U-Boot Boris Brezillon
2016-04-25 14:43 ` [U-Boot] " Boris Brezillon
2016-04-25 17:36 ` Tom Rini
2016-04-25 17:36   ` Tom Rini
2016-04-25 20:53   ` Boris Brezillon
2016-04-25 20:53     ` Boris Brezillon
2016-05-03  5:06     ` Scott Wood
2016-05-03  5:06       ` Scott Wood
2016-05-03  7:36       ` Boris Brezillon
2016-05-03  7:36         ` Boris Brezillon
2016-05-16 12:02       ` Boris Brezillon
2016-05-16 12:02         ` Boris Brezillon
2016-05-18  4:38         ` Scott Wood
2016-05-18  4:38           ` Scott Wood
2016-04-26  5:17   ` Heiko Schocher [this message]
2016-04-26  5:17     ` Heiko Schocher
2016-04-26  7:20     ` Richard Weinberger
2016-04-26  7:20       ` Richard Weinberger
2016-04-26  8:13       ` Heiko Schocher
2016-04-26  8:13         ` Heiko Schocher

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=571EFA04.4000803@denx.de \
    --to=hs@denx.de \
    --cc=alex@nextthing.co \
    --cc=boris.brezillon@free-electrons.com \
    --cc=computersforpeace@gmail.com \
    --cc=linux-mtd@lists.infradead.org \
    --cc=linux-sunxi@googlegroups.com \
    --cc=marex@denx.de \
    --cc=oss@buserror.net \
    --cc=richard@nod.at \
    --cc=scottwood@freescale.com \
    --cc=thomas.petazzoni@free-electrons.com \
    --cc=trini@konsulko.com \
    --cc=u-boot@lists.denx.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.