[U-Boot] Getting rid of board_mtdparts_default()

Enric Balletbo Serra eballetbo at gmail.com
Thu Nov 15 22:18:46 UTC 2018


Hello Boris,

Missatge de Boris Brezillon <boris.brezillon at 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.

Best regards,
  Enric

> If you don't know about the eraseblock size, maybe you
> know which OneNAND/NAND parts are used on these boards?
>
> Regards,
>
> Boris
>
> [1]https://elixir.bootlin.com/u-boot/latest/source/board/isee/igep00x0/igep00x0.c#L254
>
> --
> Boris Brezillon, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com


More information about the U-Boot mailing list