[U-Boot] [PATCH v2 0/4] ARM: imx: enhance support for the cm-fx6 module
christopher.spinrath at rwth-aachen.de
christopher.spinrath at rwth-aachen.de
Tue Jul 12 23:37:33 CEST 2016
Hi,
this is v2 of the series. To address the review comments of v1, v2 has an
addtional patch (2/4) touching include/fdt_support.h (thus, I added Simon
to the recipients).
The original cover letter was (for a discussion cf. [2]):
this series aims at enhancing support for the cm-fx6 module. In
particular, with respect to the upstream linux kernel.
The first patch improves the default environment. It is non-functional
but makes it more convenient to adapt certain settings.
The later two patches add mtd partition support for the on-board spi
flash chip. They pick up the discussion about specifying a default
partitioning in the device tree from here [1]. In short: adding the
default partitioning to the device tree was rejected by the linux/
device tree community during mainlining large parts of the device tree.
It was proposed to implement the partition/mtd handling in u-boot.
On the other hand, it was argued that the flash chip becomes some
kind of "black-box" since there will be no partition labeling (in
particular, with old u-boot versions).
IMHO defining the mtd partitioning has the following (dis-)advantages:
Advantages:
- It is easier for the user to change the partitioning (e.g. to use
the unsued 1MB free space).
- The flash ship is used entirely for u-boot. So it is quite natural
that u-boot manages it. Also, moving the partition table to it
allows us to change the layout in future versions of u-boot (almost
independently of the kernel - there are still non-device tree kernels).
- U-Boot becomes the single point of definition for all device tree
kernels. Otherwise, each kernel (vendor vs. upstream + version)
would ship its own partitioning. Moreover, u-boot has to know
something about the partitioning, too, because it has to know where
the environment is saved.
Disadvantages:
- Users of the upstream linux kernel have to use a recent u-boot
version to avoid the "black box" effect. A concrete impact is
that the update routine (described/proposed by CompuLab) does
not work out of the box with older u-boot versions.
- Updating u-boot is something users might not want or miss to do.
However, I think nowadays it is ok to demand a recent u-boot in
combination with the upstream kernel. The cm-fx6 wouldn't be
the first board doing so. Hence, I propose these patches here.
Cheers,
Christopher
[1] http://lists.infradead.org/pipermail/linux-arm-kernel/2016-June/434562.html
[2] http://lists.denx.de/pipermail/u-boot/2016-June/258546.html
More information about the U-Boot
mailing list