Missatge de Boris Brezillon <boris.brezil...@bootlin.com> del dia dj.,
15 de nov. 2018 a les 23:40:
>
> On Thu, 15 Nov 2018 23:18:46 +0100
> Enric Balletbo Serra <eballe...@gmail.com> wrote:
>
> > Hello Boris,
> >
> > Missatge de Boris Brezillon <boris.brezil...@bootlin.com> del dia dj.,
> > 15 de nov. 2018 a les 16:58:
> > >
> > > Hello Enric,
> > >
> > > Miquel and I recently reworked drivers/mtd/mtdpart.c to get MTD
> > > partitions exposed as MTD devices (as is done in Linux) instead of
> > > having yet another abstraction to handle them (see what's currently
> > > done in cmd/{mtdparts,nand,sf,...}.c).
> > >
> > > This lead us to duplicate the mtdparts/mtdids parsing logic we found in
> > > cmd/mtdparts.c, and while doing that we noticed that one function is
> > > only implemented by igep boards: board_mtdparts_default().
> > >
> > > We'd like to get rid of this function if possible in order to simplify
> > > the mtdparts/mtdids retrieval logic, and there might be an easy
> > > solution to do that: use the CONFIG_{MTDPARTS,MTDIDS}_DEFAULT config
> > > options
> > >
> > > CONFIG_MTDPARTS_DEFAULT="omap2-nand:512k(SPL),-(UBI);omap2-onenand:512k(SPL),-(UBI)"
> > > CONFIG_MTDIDS_DEFAULT="nand0=omap2-nand,onenand0=omap2-onenand"
> > >
> > > It seems those defaults were built at runtime, and the only thing I'm
> > > not sure about is whether 512k for the SPL is always good. Looks like
> > > 4 eraseblocks are reserved for the SPL [1], but is the eraseblock size
> > > always 128k?
> >
> > No, there are boards in the field that doesn't have and eraseblock
> > size of 128k, as far as I can remember there are at least boards with
> > an eraseblock of 64k, I don't remember though, boards with and
> > eraseblock size greater than 128k. About the 4 eraseblocks, there is a
> > reason for this., the blocks are reserved for the SPL because you can
> > flash 4 times (once per block) the SPL, the ROM code looks for an
> > image in the first four blocks and it detects the validity status of
> > these blocks. So, if the first one is corrupted, boots from the
> > second, if the second is corrupted looks for the third, etc.
> >
> > Said this, I think that the main question is if it's fine to get rid
> > of this code. Ideally, we should cover all the cases, so assuming that
> > there aren't devices with an eraseblock size greater than 128k,
> > reserve 512k seems a good number. There is, though, a corner case
> > where this number is not fine. There are some boards that came with a
> > OneNand(DDP), the ROM code is only capable to read the odd blocks (1,
> > 3, 5, 7...). So, in this case, you need to reserve 896k (128k NA 128k
> > NA 128k NA 128k ). Fwiw that was also not covered with current code.
> >
> > To be honest, I wouldn't worry about this latest case, and in my
> > opinion, a fixed size of 512k is enough. Also, it's common now that
> > the first few blocks of NAND flash are guaranteed to be safe for the
> > first N erase cycles. So, I'm fine with the proposed fixed 512k for
> > SPL. Btw, good job.
>
> Okay, so next question is, does anyone rely on the default
> partitioning? If that's the case we're screwed because using something
> different will break things (UBI will be smaller than expected and
> complain that blocks are missing).I don't rely on the default partitioning and the few people I know also don't rely on it. I can't talk for everyone as is more than 3 year I left from the company that makes the IGEP, although I am pretty sure nobody relies on it. That partioning is the most common, so my suggestion is to go ahead and let's see if somebody complains. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de https://lists.denx.de/listinfo/u-boot
