All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ladislav Michl <ladis@linux-mips.org>
To: u-boot@lists.denx.de
Subject: [U-Boot] [PATCH 2/2] mtd: Get rid of board_mtdparts_default()
Date: Wed, 12 Dec 2018 12:37:04 +0100	[thread overview]
Message-ID: <20181212113704.GA23132@lenoch> (raw)
In-Reply-To: <20181212103251.1a44b57c@bbrezillon>

Hello Boris,

On Wed, Dec 12, 2018 at 10:32:51AM +0100, Boris Brezillon wrote:
> Hi Ladislav,
> 
> On Tue, 11 Dec 2018 23:55:26 +0100
> Ladislav Michl <ladis@linux-mips.org> wrote:
> 
> > Hi Boris,
> > 
> > On Mon, Dec 10, 2018 at 04:38:50PM +0100, Boris Brezillon wrote:
> > > The only implementer of this function has been patched to use
> > > CONFIG_MTD{IDS,PARTS}_DEFAULT instead. Let's get rid of this function
> > > and the associated CONFIG_SYS_MTDPARTS_RUNTIME option.  
> > 
> > the only implementer of this fuction did so for a good reason. What is
> > a motivation to remove it?
> 
> Simplifying the code (see this discussion [1] which led me to send
> this patchset).

Thank you, makes sense.

> > The requirement is to be able to use single u-boot binary on all igep2
> > boards ever produced. These comes with various NAND and OneNAND chips
> > and  I was not able to come with single static partition configuration
> > to support them all.
> 
> That's actually the question I asked Enric in [1]. Can you list all
> the memory organization you have (for NAND and OneNAND chips)? I mean,
> the SPL part size depends on the NAND/OneNAND erase block size, and
> board vendors try to use similar flashes when they source different
> parts (same page size, same block size, ...). Assuming this is the
> case, you should always have the same layout for OneNAND/NAND devices,
> hence my proposal to define those parts statically.

First, thanks to Enric for pinging me, otherwise I would probably miss this
completely.

Now problem is that IGEPv2 comes with quite many configurations, some of
them are even customized, so static configuration is a show stopper
mainly as I do not know what devices are in field.
Another issue is how ubispl code works: It expects struct ubispl_info
filled with (among others) peb_offset of ubi partition. ubispl code counts
in terms of eraseblocks regardless of their size. So we would need to touch
this number when using static mtdparts.

> > Hence runtime detection. That code could be used
> > on all OMAP3 boards as BootROM reads up to first four sectors searching
> > for SPL (MLO).
> 
> Note that, for the nand side of things, you can also automate that using
> a u-boot script:
> 
> nand info; setexpr splsize ${nand_erasesize} * 4; setenv mtdparts mtdparts=omap2-nand:0x${splsize}(SPL),-(UBI)

That seems as a way to go!

> Shouldn't be hard to patch the onenand cmd to also expose writesize,
> erasesize and oobsize.

Side note: I never fully understand why is OneNAND using separate set of
commands.

Could you hold merging your paches until I implement above idea and test
it on a few boards? I know u-boot is now using two months merge window,
which is unfortunate, so I'll try to do it as soon as possible, but I do
not think I'll finish it till end of week.

> Regards,
> 
> Boris
> 
> [1]https://www.mail-archive.com/u-boot at lists.denx.de/msg304933.html

  reply	other threads:[~2018-12-12 11:37 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-12-10 15:38 [U-Boot] [PATCH 1/2] configs: igep: Define default mtdids/mtdparts Boris Brezillon
2018-12-10 15:38 ` [U-Boot] [PATCH 2/2] mtd: Get rid of board_mtdparts_default() Boris Brezillon
2018-12-10 21:50   ` Enric Balletbo Serra
2018-12-11 22:55   ` Ladislav Michl
2018-12-12  9:32     ` Boris Brezillon
2018-12-12 11:37       ` Ladislav Michl [this message]
2018-12-12 17:36         ` Boris Brezillon
2018-12-21 10:26           ` Enric Balletbo Serra
2018-12-10 21:50 ` [U-Boot] [PATCH 1/2] configs: igep: Define default mtdids/mtdparts Enric Balletbo Serra
2018-12-21 10:22   ` Enric Balletbo Serra

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=20181212113704.GA23132@lenoch \
    --to=ladis@linux-mips.org \
    --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.